From 76823e31d443b297f41fad54312aa4feb75a5bcf Mon Sep 17 00:00:00 2001 From: Bharathkumar Date: Wed, 21 Jan 2026 20:12:35 +1100 Subject: [PATCH 1/2] added Data protection policy Documentation --- docs/company-policy/Data Protection Policy.md | 441 ++++++++++++++++++ 1 file changed, 441 insertions(+) create mode 100644 docs/company-policy/Data Protection Policy.md diff --git a/docs/company-policy/Data Protection Policy.md b/docs/company-policy/Data Protection Policy.md new file mode 100644 index 000000000..7bdd41fd6 --- /dev/null +++ b/docs/company-policy/Data Protection Policy.md @@ -0,0 +1,441 @@ +**Data Protection Policy** + +**Redback Operations** + +**1\. Introduction** + +Redback Operations is a student-led team that develops innovative projects integrating IoT sensors, web and mobile applications, data analytics pipelines, and Unity VR environments. In the course of these projects, the team handles various forms of data from personal user information and sensor readings to internal documentation and code. This **Data Protection Policy** outlines how Redback Operations protects all such data, ensuring its confidentiality, integrity, and availability. By adhering to this policy, the team builds trust with users and stakeholders and aligns with Australian privacy laws and best practices in information security. + +This policy establishes a formal framework for responsible data handling within Redback. It defines how data is classified, who can access it, how it must be secured, and the procedures for data retention and breach response. The tone and expectations are set at a level appropriate for a student team environment while remaining professionally acceptable to academic supervisors and industry evaluators. All Redback team members are expected to be familiar with and follow this policy to maintain high standards of data protection throughout our project lifecycle. + +**2\. Purpose & Scope** + +**Purpose** +The purpose of the Data Protection Policy is to ensure that Redback Operations manages data in compliance with relevant laws and ethical standards, and that all data collected, generated, or used by the team is protected against unauthorized access or misuse. This policy aims to safeguard personal information, project data, and intellectual property by providing clear guidelines on handling, storing, and sharing data. It also seeks to instill good data management habits in team members, reflecting both professional IT security practices and the requirements of Australian privacy regulations. + +**Scope** +This policy applies to **all data assets and systems** used in Redback Operations. It covers every project and sub-team under Redback, including: + +- IoT devices and sensors +- Backend servers, APIs, and data pipelines (e.g. MQTT, Kafka, FastAPI) +- Web and mobile applications +- Databases and data lakes (PostgreSQL, MongoDB, MinIO, Dremio, etc.) +- Unity VR environments and associated services +- Internal documentation, reports, and communication channels + +All team members (students, faculty advisors, and collaborators) must comply with these guidelines when handling data. The scope extends to all forms of data – digital or physical, structured (like databases) or unstructured (like documents or media files). It also includes any personal information about individuals (such as team members or pilot users) and any sensitive project information. Whether data is stored on on-prem servers, cloud services, team laptops, or transferred through networks, it falls under this policy. External parties who are given access to Redback data are expected to uphold equivalent data protection standards. + +**3\. Data Categories & Systems** + +Redback Operations handles multiple categories of data across a range of systems. Identifying these data types and systems is crucial to applying appropriate protection measures. + +**3.1 Systems and Platforms** + +- **IoT Devices and Sensors** + Smartbike sensors and other wearables stream telemetry data (e.g. speed, cadence, heart rate, IMU readings) via MQTT/Kafka into backend services. +- **Web and Mobile Applications** + The Redback dashboard and mobile app handle user registrations, authentication, profiles, and personalised performance analytics. +- **Data Processing Pipelines and Services** + Backend services (FastAPI, MQTT/Kafka brokers, Airflow jobs) ingest, transform, and route data between components and into storage or analytics tools. +- **Databases and Storage** + - Relational and document databases (e.g. PostgreSQL, MongoDB) + - Object storage (e.g. MinIO) for files, exports, model artefacts + - Code repositories (e.g. GitHub) for source code and configuration +- **Unity VR Environment** + The Unity VR application consumes live or near-real-time data (via APIs/WebSockets/MQTT) to drive gameplay, visualisations, and feedback. + +**3.2 Data Categories** + +- **Personal Data** + Information relating to an identified or identifiable person, such as: + - Names, email addresses, usernames, student IDs + - Contact details, profile info, preferences + - Credentials (usernames, salted/hashed passwords, auth tokens) +- **Telemetry and Sensor Data** + Data from IoT devices and wearables, including: + - Heart rate, power, cadence, speed, IMU readings + - Device IDs, timestamps, location (if used) + +When linked to a person or containing health-related metrics, this is treated as sensitive personal data. + +- **Project Operational Data** + Internal data used to operate and monitor systems: + - Application and infrastructure logs + - Configuration files and environment settings + - Performance metrics, error reports, traces +- **Intellectual Property & Research Data** + - Source code, algorithms, Unity scenes and assets + - Designs, architecture diagrams, documentation + - Research datasets (e.g. curated wearables data, annotation sets) + - Partner-provided data (e.g. under NDA or specific licence terms) +- **Aggregated and Derived Data** + - Analytics outputs, dashboards, summary statistics + - ML model outputs, derived features, trained model parameters + - Visualisations and reports built from underlying data + +Each category is subject to classification and protection measures described in the next section. + +**4\. Classification Framework** + +All data handled by Redback is classified into one of four sensitivity levels. Classification determines how data must be stored, accessed, and shared. + +**4.1 Classification Levels** + +**Public** (Low Sensitivity) +Information intended for open sharing that poses minimal risk if disclosed. +Examples: + +- Public documentation and marketing content +- Open-source code repositories intentionally published +- Approved public presentations and demo screenshots + +**Internal** (Team-Only) +Information for internal consumption within Redback only. +Examples: + +- Internal design docs, sprint notes, retrospective notes +- Non-sensitive emails or chat messages about project work +- Non-public architecture diagrams and planning documents + +**Confidential** (Sensitive) +Information that could cause harm if disclosed or tampered with. +Examples: + +- Personal data of team members or test users +- Health and performance metrics linked to individuals +- Detailed system configurations, internal API docs +- Partner-provided datasets or documents under NDA + +**Highly Confidential** (Restricted) +Information that is critical to system security or highly sensitive. +Examples: + +- Root passwords, private keys, API secrets, tokens +- Unanonymised research data involving human subjects +- Detailed security audit reports and threat models + +**4.2 Classification Principles** + +- When in doubt, treat data as **Confidential** or **Highly Confidential**. +- Personal data is **at least Confidential**; authentication secrets are **Highly Confidential**. +- Files, screenshots and exports inherit the highest classification of any data they contain. +- Classification should be applied at creation and reviewed if data usage changes. + +**5\. Access, Use & Disclosure** + +Redback applies **least privilege** and **need-to-know** principles to all data access. + +**5.1 Access Control** + +- Access to Internal, Confidential and Highly Confidential data is restricted to those who need it for their role. +- Role-based access control (RBAC) is implemented for: + - Databases and data warehouses + - Storage buckets (e.g. MinIO) + - Analytics tools and dashboards + - CI/CD and infrastructure management tools +- Administrative and root-level access is limited to designated leads (e.g. DevOps/Security leads). +- Shared credentials are avoided; each person uses their own account wherever possible. + +**5.2 Authentication & Sessions** + +- Strong passwords or passphrases are required; password reuse is discouraged. +- Multi-factor authentication (MFA) is enabled for critical systems where available (e.g. cloud consoles, GitHub orgs). +- Sessions for web/mobile/VR applications are time-limited and securely managed. +- Devices used for Redback work must have screen locks and up-to-date security patches. + +**5.3 Use of Data** + +- Data is used only for **clearly defined project purposes**, such as: + - Delivering app functionality + - Improving performance and user experience + - Conducting agreed research and evaluation +- Data minimisation is applied: + - Only collect what is necessary + - Only query the subset needed for a specific task + - Prefer aggregated/anonymised data when identity is not required +- Any new or secondary use of data (beyond original purpose) must be reviewed and, if personal data is involved, justified and documented. + +**5.4 Consent and Participant Rights** + +Where real individuals’ data is collected (e.g. test users, volunteers): + +- They are informed about: + - What data is collected + - For what purpose + - How long it will be kept + - How it will be protected +- Consent is recorded (e.g. via a short form or online acknowledgment). +- On reasonable request, participants can: + - Ask what data is held about them + - Request corrections if information is inaccurate + - Request deletion or anonymisation where feasible and consistent with project requirements + +**5.5 Internal & External Disclosure** + +- Internal disclosure is limited to team members who need the data for project tasks. +- External disclosure of Confidential or Highly Confidential data: + - Requires explicit approval from project leads + - Should use anonymisation/aggregation wherever possible + - Must be communicated over secure channels +- Personal information is not shared with third parties unless: + - It is required by law or university policies, or + - Explicit consent has been obtained from the individual +- Sensitive data must **never** be posted in: + - Public GitHub repos + - Public chat channels or forums + - Slides, screenshots or demos destined for external audiences, unless sanitised + +**6\. Security Expectations** + +Security is everyone’s responsibility. The following controls apply across Redback systems. + +**6.1 Device, Infrastructure & Network Security** + +- Keep all servers, containers, and devices patched and updated. +- Disable unused ports and services; enforce firewall rules. +- Use secure network paths (VPNs or restricted subnets) for administration access. +- Harden IoT devices: + - Change default credentials + - Remove unnecessary software and services + - Apply firmware updates promptly + +**6.2 Application & API Security** + +- Apply secure coding practices and review code for common vulnerabilities (e.g. OWASP Top 10). +- Validate all inputs; avoid directly trusting client-side data. +- Do not hard-code secrets in source code; use environment variables or secret managers. +- Protect REST and WebSocket APIs with appropriate authentication and authorisation. + +**6.3 Identity & Access Management** + +- Use RBAC in databases, dashboards, and admin tools. +- Limit high-privilege accounts and protect them with MFA. +- Immediately disable accounts for team members who leave the project. +- Keep an auditable record of role assignments and access changes. + +**6.4 Data Protection Controls** + +- Encrypt Confidential and Highly Confidential data at rest where feasible. +- Enforce TLS for: + - Web and API endpoints + - MQTT/Kafka links carrying sensitive payloads + - Database connections from remote clients +- Restrict who can export data and where exports may be stored. +- Sanitize or anonymise data before using it in presentations, documentation, or demos. + +**6.5 Monitoring, Logging & Testing** + +- Enable logging on critical systems (auth events, configuration changes, error conditions). +- Use monitoring tools (e.g. Wazuh, metrics dashboards) to detect anomalies. +- Conduct: + - Regular vulnerability scans + - Periodic manual security reviews + - Targeted penetration tests within agreed scope +- Address identified vulnerabilities in a timely and documented way. + +**6.6 Backups & Recovery** + +- Regularly back up critical data (databases, configs, key artefacts). +- Store backups securely and, where possible, encrypted. +- Test recovery procedures so that data and services can be restored after failure or incident. + +**7\. Retention & Disposal** + +Redback keeps data only as long as necessary and disposes of it securely when no longer required. + +**7.1 Retention** + +- **Project data & records** + - Retained for the duration of the project and a reasonable period afterward for continuity and assessment. +- **Personal information** + - Retained only as long as needed to achieve the purpose it was collected for. + - Removed or anonymised when: + - The project is completed and the data is no longer needed + - The participant withdraws consent (where feasible) +- **Logs & monitoring data** + - Kept for limited periods (e.g. 3–6 months) for troubleshooting and security monitoring, then rotated or deleted. +- **Backups** + - Retained in line with backup schedules and removed when obsolete. + +**7.2 Archiving & Anonymisation** + +- Where long-term insights are useful, data should be **anonymised** or **aggregated** before archival. +- Direct identifiers (names, emails, IDs) are removed or irreversibly transformed. +- Anonymised datasets can often be retained as Internal rather than Confidential. + +**7.3 Secure Disposal** + +- **Digital data** + - Delete records from databases and storage systems. + - For sensitive data, use secure deletion or destroy encryption keys where applicable. +- **Physical media** + - Shred printed documents containing Confidential or Highly Confidential information. + - Wipe or physically destroy drives and removable media before disposal or reuse. +- **Cloud and third-party services** + - Explicitly delete project data and instances when no longer required, not just “abandon” them. + +Basic records of major deletions/archivals should be kept for accountability (e.g. “Participant test dataset deleted on <date>”). + +**8\. Breach Management** + +A **data breach** occurs when data is lost, accessed, or disclosed without authorisation, or is altered/destroyed in an unauthorised way. + +**8.1 Reporting** + +All team members must **immediately report** suspected or confirmed data breaches to the project lead and the designated security/contact person. Examples: + +- Unexpected data exposure in a public repo +- Loss/theft of a laptop containing project data +- Logs or dashboards showing access from unknown users or locations + +**8.2 Containment** + +Initial response focuses on stopping further damage: + +- Revoke or rotate compromised credentials (passwords, API keys, tokens). +- Disable affected services or interfaces temporarily if needed. +- Isolate compromised systems from the network. + +**8.3 Assessment** + +After containment, the team: + +- Identifies: + - What happened and how + - Which systems and datasets are affected + - Whether personal or Highly Confidential data is involved +- Evaluates the **risk of harm** to individuals and to Redback/Deakin (e.g. identity misuse, reputational harm, security threats). + +**8.4 Notification** + +If personal information is involved and serious harm is likely: + +- Notify affected individuals promptly with: + - What occurred + - What data was involved + - What steps they should take (e.g. change passwords) +- Follow the principles of the **Notifiable Data Breaches (NDB) scheme**, including notifying the OAIC if the project falls under those obligations. +- Inform faculty supervisors or relevant university contacts in line with Deakin policies. + +Even if not strictly required, Redback favours transparency with supervisors and stakeholders. + +**8.5 Remediation & Recovery** + +- Fix root causes (patch vulnerabilities, correct misconfigurations, improve access controls). +- Restore systems and data from clean backups where necessary. +- Increase logging or monitoring temporarily to detect any follow-up activity. + +**8.6 Post-Incident Review** + +- Document the incident, response steps, and outcomes. +- Conduct a short review with the team: + - What went wrong? + - What worked well? + - What needs to change? +- Update this policy, procedures, or training if gaps are identified. + +**9\. Ethical & Compliance Alignment** + +Redback’s data protection practices are grounded in both **legal** and **ethical** expectations. + +**9.1 Legal Alignment (High-Level)** + +This policy is designed to align with: + +- **Privacy Act 1988 (Cth)** – primary Australian privacy legislation[OAIC+1](https://www.oaic.gov.au/privacy/privacy-legislation/the-privacy-act?utm_source=chatgpt.com) +- **Australian Privacy Principles (APPs)** – especially: APP 1 (transparency), APP 3 (collection), APP 6 (use & disclosure), APP 11 (security), APP 12–13 (access & correction)[OAIC+1](https://www.oaic.gov.au/privacy/australian-privacy-principles?utm_source=chatgpt.com) +- **Notifiable Data Breaches (NDB) scheme** – guidance on identifying and responding to eligible data breaches (likely to cause serious harm)[OAIC+2OAIC+2](https://www.oaic.gov.au/privacy/notifiable-data-breaches/about-the-notifiable-data-breaches-scheme?utm_source=chatgpt.com) + +While Redback operates as a student capstone project and may not be a formal APP entity, we treat these as best-practice benchmarks. + +**9.2 Ethical Alignment** + +Redback aligns with the **Australian Computer Society (ACS) Code of Professional Ethics**, including values of honesty, trustworthiness, and respect for privacy.[ACS+2Zaco+2](https://www.acs.org.au/memberships/professional-ethics-conduct-and-complaints.html?utm_source=chatgpt.com) + +Practically, this means: + +- Avoiding unnecessary collection or retention of personal data +- Treating any human-related data (especially health metrics) with care and respect +- Being honest and transparent about how data is used +- Speaking up if something feels ethically wrong in how data is handled + +**9.3 Standards & Good Practice** + +Where practical, this policy draws on: + +- **ASD Essential Eight** mitigation strategies for securing systems[Cyber.gov.au+2Cyber.gov.au+2](https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight?utm_source=chatgpt.com) +- Broader security frameworks such as ISO/IEC 27001 (information security management) +- University information security and research ethics guidelines + +These are used as guidance, not strict certifications, to ensure Redback is aligned with contemporary cybersecurity and privacy expectations. + +**10\. Governance & Review** + +**10.1 Roles & Responsibilities** + +**Project Leadership (e.g. Project Manager / Technical Lead)** + +- Owns this policy and ensures it is applied. +- Makes decisions on edge cases (e.g. new datasets, new third-party tools). +- Ensures necessary tools and time for security tasks (e.g. code reviews, patches). + +**Data Steward (can be one of the leads)** + +- Oversees data classification and retention decisions. +- Maintains awareness of what data exists where. +- Coordinates responses to access/correction/deletion requests. + +**Security / DevOps Lead** + +- Manages infrastructure security, access controls, backups, and monitoring. +- Coordinates technical breach response. +- Ensures secrets management and secure configurations are in place. + +**Documentation / Compliance Lead** + +- Keeps policies, procedures, and diagrams up-to-date. +- Ensures new members are onboarded with this policy. +- Coordinates periodic reviews and updates. + +**All Team Members** + +- Read and follow this policy. +- Protect credentials and devices used for project work. +- Raise potential issues, incidents, or uncertainties early. + +**10.2 Training & Onboarding** + +- New members receive an introduction to this policy and key expectations. +- Short refreshers are provided when: + - Policies are updated + - New systems are introduced + - Lessons are learned from incidents or near misses + +**10.3 Review Cycle** + +- This policy is reviewed **at least annually** and at the start of major new project phases. +- Reviews consider: + - Changes in laws or university policies + - New tools, infrastructure, or data flows + - Feedback from team members and evaluators + - Lessons learned from any incidents +- Changes are versioned, documented, and communicated to the team. + +**10.4 Enforcement** + +- Adherence to this policy is mandatory for all Redback members. +- Accidental breaches are treated as learning opportunities, but must be reported and rectified. +- Repeated or serious non-compliance may lead to: + - Restricted access to systems or data + - Escalation to academic supervisors + +The focus is on improvement, accountability, and professionalism, not punishment. + +**References & Further Reading** + +- Privacy Act 1988 – Australian Government (Attorney-General’s Department)[OAIC+1](https://www.oaic.gov.au/privacy/privacy-legislation/the-privacy-act?utm_source=chatgpt.com) +- Australian Privacy Principles (APPs) – OAIC overview and quick reference[OAIC+1](https://www.oaic.gov.au/privacy/australian-privacy-principles?utm_source=chatgpt.com) +- APP Guidelines – OAIC detailed PDF guidance[OAIC+1](https://www.oaic.gov.au/__data/assets/pdf_file/0009/1125/app-guidelines-july-2019.pdf?utm_source=chatgpt.com) +- Notifiable Data Breaches (NDB) Scheme – OAIC overview and guidance[OAIC+2OAIC+2](https://www.oaic.gov.au/privacy/notifiable-data-breaches/about-the-notifiable-data-breaches-scheme?utm_source=chatgpt.com) +- ACS Code of Professional Ethics – Australian Computer Society[ACS+2Zaco+2](https://www.acs.org.au/memberships/professional-ethics-conduct-and-complaints.html?utm_source=chatgpt.com) +- Essential Eight – Australian Signals Directorate / ACSC guidance[Cyber.gov.au+2Cyber.gov.au+2](https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight?utm_source=chatgpt.com) \ No newline at end of file From f5ed7ad137869fdab653ec9cdb2567ecb4ca6136 Mon Sep 17 00:00:00 2001 From: Bharathkumar Date: Wed, 8 Apr 2026 18:52:57 +1000 Subject: [PATCH 2/2] Add ModSecurity CRS Rule Analysis report --- ...Rule Analysis and Classification Report.md | 528 ++++++++++++++++++ 1 file changed, 528 insertions(+) create mode 100644 docs/cybersecurity/Blue Team/ModSecurity CRS Rule Analysis and Classification Report.md diff --git a/docs/cybersecurity/Blue Team/ModSecurity CRS Rule Analysis and Classification Report.md b/docs/cybersecurity/Blue Team/ModSecurity CRS Rule Analysis and Classification Report.md new file mode 100644 index 000000000..4b5d5b9d8 --- /dev/null +++ b/docs/cybersecurity/Blue Team/ModSecurity CRS Rule Analysis and Classification Report.md @@ -0,0 +1,528 @@ +**ModSecurity CRS Rule Analysis and Classification Report** + +**1\. Introduction** + +Modern web applications are continuously exposed to a wide range of automated and targeted cyber threats, including injection attacks, remote code execution attempts, and reconnaissance scanning. To defend against such threats, organisations deploy Web Application Firewalls (WAFs) that provide real-time inspection and filtering of HTTP traffic. One of the most widely adopted open-source WAF solutions is ModSecurity, which operates by applying predefined and custom security rules to incoming requests. + +A key component of ModSecurity is the OWASP Core Rule Set (CRS), a comprehensive collection of generic attack detection rules developed and maintained by the Open Web Application Security Project (OWASP). The CRS is designed to identify and mitigate common web-based attacks such as SQL injection (SQLi), Cross-Site Scripting (XSS), Local File Inclusion (LFI), and Remote Code Execution (RCE), using a rule-based anomaly scoring system. Each rule is assigned a unique identifier (Rule ID) and contributes to an overall anomaly score that determines whether a request should be allowed, logged, or blocked.While the CRS provides strong baseline protection, its generic nature often results in high volumes of alerts, particularly in environments exposed to automated scanning tools and internet-wide reconnaissance activity. This can lead to **log noise**, where large numbers of benign or non-actionable alerts obscure meaningful security events. As a result, effective WAF operation requires not only deployment but also **continuous analysis, validation, and tuning of CRS rules**. + +This documentation focuses on the systematic analysis of CRS rule triggers observed within the Redback Operations environment. The primary objective is to map Rule IDs to their corresponding attack categories, understand the behaviour and intent of detected traffic, and distinguish between genuine threats and noise generated by automated scanning. Special attention is given to repeated high-frequency alerts associated with /cgi-bin/\* endpoints, which were identified as a significant source of log noise. + +Through this analysis, the document aims to: + +* Provide clear visibility into how CRS rules function in a real-world environment +* Identify dominant attack patterns and their underlying causes +* Evaluate the effectiveness of the current WAF configuration +* Support informed decision-making for safe and targeted rule tuning + +Ultimately, this work contributes to improving the **signal-to-noise ratio** in WAF logging, ensuring that security teams can focus on actionable threats while maintaining robust protection against real-world attacks. + +**2\. Environment Overview** + +The analysis was conducted within the Redback Operations infrastructure, which is designed to simulate a real-world enterprise environment with multiple interconnected services. The system architecture incorporates a reverse proxy layer, containerised applications, and centralised security monitoring, providing a practical setting for evaluating Web Application Firewall (WAF) behaviour under realistic conditions. + +At the core of the web security layer is an Nginx-based reverse proxy integrated with ModSecurity. This proxy is deployed as a container (nginx.modsecurity) and is responsible for handling inbound HTTP/HTTPS traffic, enforcing security rules, and routing requests to backend services. ModSecurity operates in conjunction with the OWASP Core Rule Set, which provides a predefined set of detection rules for identifying malicious or anomalous requests. + +The environment is built using Docker, where multiple services including application backends, monitoring tools, and supporting infrastructure are deployed as isolated containers. The reverse proxy serves as the primary entry point, ensuring that all external traffic is inspected before reaching internal services. This architecture enables effective traffic filtering, logging, and enforcement of security policies at a centralised point. + +For this analysis, ModSecurity logs were obtained directly from the container using Docker logging mechanisms. These logs capture detailed information about each triggered rule, including Rule IDs, request URIs, client IP addresses, and anomaly scores. To facilitate structured analysis, a custom Python-based log processing pipeline was used to extract, aggregate, and summarise this data into multiple formats, including Markdown reports, CSV files, and JSON datasets. + +The scope of the analysis focused on recent log data collected over defined time windows (typically 24 hours), with additional comparisons across multiple days to identify recurring patterns. Key metrics examined include: + +* Total number of WAF alerts (rule hits) +* Frequency distribution of Rule IDs +* Unique request URIs and endpoints +* Client IP activity and concentration +* Transaction-level behaviour and repetition + +The environment also supports auxiliary security tooling, such as Wazuh for vulnerability detection and monitoring, which complements the WAF by providing broader visibility into system-level events. However, this document primarily concentrates on ModSecurity and CRS rule behaviour within the web traffic layer. + +Overall, this controlled yet realistic environment enables a comprehensive evaluation of WAF performance, highlighting both its effectiveness in detecting threats and the challenges associated with managing high volumes of log data generated by automated scanning activity. + +**3\. Methodology** + +A structured and systematic approach was followed to analyse ModSecurity logs, map CRS rule behaviour, and identify sources of log noise within the environment. The methodology combines log extraction, rule mapping, behavioural analysis, and validation techniques to ensure accurate interpretation of security events. + +**3.1 Log Collection and Extraction** + +ModSecurity alert logs were collected directly from the reverse proxy container using Docker logging commands. The following approach was used: + +* Extract logs from the nginx.modsecurity container +* Filter relevant entries containing ModSecurity alerts and request details +* Focus on recent activity using defined time windows (e.g., last 24 hours) + +This ensured that the dataset represented current system behaviour while remaining manageable for analysis. + +**3.2 Data Processing and Report Generation** + +To enable structured analysis, a custom log processing pipeline was utilised. The pipeline performed the following tasks: + +* Parsed raw log entries to extract: + * Rule IDs + * Request URIs + * Client IP addresses + * Transaction identifiers +* Aggregated rule frequency counts +* Identified top triggering rules and endpoints +* Generated outputs in: + * Markdown reports (for human-readable summaries) + * CSV files (for quantitative analysis) + * JSON files (for structured data processing) + +This step transformed unstructured logs into meaningful datasets that could be systematically analysed. + +**3.3 Rule Mapping and Classification** + +Each observed Rule ID was mapped to its corresponding rule definition within the OWASP Core Rule Set. This was achieved by: + +* Extracting rule definitions from CRS configuration files inside the container +* Identifying: + * Rule messages (msg) + * Tags (tag) indicating attack categories + * Associated CRS rule files + +Based on this mapping, rules were categorised into attack types such as: + +* Scanner Detection +* Protocol Enforcement +* Local File Inclusion (LFI) +* Remote Code Execution (RCE) +* Cross-Site Scripting (XSS) +* SQL Injection (SQLi) +* Anomaly Scoring / Blocking Evaluation + +This classification enabled a deeper understanding of the nature of detected traffic. + +**3.4 Behavioural Analysis of Traffic Patterns** + +To distinguish between legitimate activity and noise, multiple behavioural indicators were analysed: + +* **Frequency Analysis:** + Identification of high-frequency Rule IDs contributing to the majority of alerts +* **Endpoint Analysis:** + Detection of repeatedly accessed URIs, particularly /cgi-bin/\* paths +* **Client IP Analysis:** + Observation that a single or small number of IPs generated a large proportion of alerts +* **Pattern Consistency:** + Verification that the same endpoints and rules appeared consistently across multiple days +* **Request Characteristics:** + Examination of request payloads for known attack signatures (e.g., ../, /etc/passwd, command injection patterns) + +These indicators were used to identify automated scanning behaviour and differentiate it from legitimate user activity. + +**3.5 Validation of Application Relevance** + +To ensure accurate classification of false positives, additional validation steps were performed: + +* Checked Nginx configuration to verify whether /cgi-bin/\* endpoints were routed to any backend service +* Tested selected endpoints using HTTP requests (e.g., curl) +* Confirmed that these endpoints consistently returned error responses (e.g., 404 Not Found) +* Verified absence of /cgi-bin references within application routing configurations + +This confirmed that the observed requests were targeting non-existent endpoints and were not part of legitimate application functionality. + +**3.6 Multi-Day Log Comparison** + +To strengthen the analysis, log data from multiple days was compared to identify recurring patterns. This included: + +* Comparing rule frequency distributions across reports +* Verifying consistency in triggering endpoints +* Confirming repeated activity from similar client IP ranges + +This step provided strong evidence that the observed behaviour was persistent and automated rather than isolated incidents. + +**3.7 Tuning and Validation Approach** + +A controlled tuning strategy was applied to reduce log noise while maintaining security coverage. The approach included: + +* Implementing scoped ModSecurity rules targeting specific patterns (e.g., /cgi-bin/\*) +* Avoiding global rule disabling to prevent weakening protection +* Applying logging suppression techniques (nolog) rather than removing detection logic +* Monitoring changes in alert volume after tuning +* Validating that no legitimate application traffic was affected + +The effectiveness of tuning was evaluated by comparing alert metrics before and after implementation. + +**3.8 Key Objective of Methodology** + +The overall objective of this methodology was to: + +* Accurately interpret WAF alerts +* Identify dominant sources of log noise +* Validate whether alerts represent real threats or benign activity +* Enable safe and targeted optimisation of CRS rules + +This structured approach ensures that tuning decisions are evidence-based and do not compromise the security posture of the system. + +**4\. CRS Rule Categorization Overview** + +The analysis of ModSecurity logs revealed that a diverse set of rules from the OWASP Core Rule Set were triggered during the observation period. These rules span multiple security categories, each designed to detect specific types of web-based attacks or anomalous behaviour. + +To provide clarity and structure, the identified Rule IDs were grouped into logical categories based on their associated CRS rule files, tags, and detection purpose. This categorisation enables a clearer understanding of the nature of incoming traffic and helps distinguish between genuine attack attempts and non-actionable noise. + +**4.1 Summary of Rule Categories** + +| Category | CRS Rule Range / Files | Description | +| --- | --- | --- | +| Scanner Detection | REQUEST-913 | Identifies automated scanning tools based on User-Agent and behaviour | +| Protocol Enforcement | REQUEST-920 | Detects malformed or non-compliant HTTP requests | +| Local File Inclusion (LFI) | REQUEST-930 | Identifies attempts to access sensitive files (e.g., /etc/passwd) | +| Remote Code Execution (RCE) | REQUEST-932 | Detects command injection and execution attempts | +| PHP Injection | REQUEST-933 | Identifies PHP-specific injection patterns | +| Cross-Site Scripting (XSS) | REQUEST-941 | Detects malicious scripts injected into requests | +| SQL Injection (SQLi) | REQUEST-944 | Identifies database query manipulation attempts | +| Blocking Evaluation | REQUEST-949 | Calculates anomaly score and determines whether to block requests | + +**4.2 Interpretation of Categories in Context** + +**Scanner Detection (REQUEST-913)** + +Rules in this category identify known scanning tools through patterns such as User-Agent strings. In the observed logs, these rules were frequently triggered by requests associated with automated tools, indicating widespread reconnaissance activity targeting the system. + +**Protocol Enforcement (REQUEST-920)** + +These rules enforce compliance with HTTP standards by detecting malformed or suspicious requests. High activity in this category typically indicates automated tools sending irregular or incomplete requests, rather than legitimate user traffic. + +**Local File Inclusion – LFI (REQUEST-930)** + +LFI rules detect attempts to access sensitive files through path traversal techniques (e.g., ../../etc/passwd). The presence of these rules in the logs confirms that attackers or scanners are attempting to exploit file access vulnerabilities. + +**Remote Code Execution – RCE (REQUEST-932)** + +RCE rules identify attempts to execute system-level commands via web inputs. These are considered high-risk attack patterns and are commonly used in exploitation attempts against vulnerable applications. + +**PHP Injection (REQUEST-933)** + +These rules detect malicious PHP payloads embedded in requests. Their presence indicates attempts to manipulate backend application logic or execute unintended code. + +**Cross-Site Scripting – XSS (REQUEST-941)** + +XSS rules identify injection of JavaScript or HTML into web inputs. These attacks aim to compromise client-side execution and are critical to detect in web-facing applications. + +**SQL Injection – SQLi (REQUEST-944)** + +SQLi rules detect attempts to manipulate database queries. These are among the most critical web vulnerabilities and require strict enforcement without relaxation. + +**Blocking Evaluation (REQUEST-949)** + +This category plays a central role in ModSecurity’s anomaly scoring system. Rather than detecting a specific attack, these rules evaluate the cumulative score of triggered rules and determine whether a request should be blocked. High frequency of Rule 949110 indicates that multiple suspicious behaviours are being detected within individual requests. + +**4.3 Key Observations from Categorization** + +From the categorised analysis, several important insights were identified: + +* A significant portion of alerts originated from **scanner detection and protocol enforcement rules**, indicating a high volume of automated scanning activity +* Critical attack categories such as **LFI, RCE, SQLi, and XSS** were also triggered, confirming the presence of real attack attempts +* The frequent triggering of **blocking evaluation rules (949110)** suggests that many requests accumulate high anomaly scores, reinforcing the effectiveness of the WAF +* The majority of these alerts were associated with **non-existent endpoints**, particularly /cgi-bin/\*, indicating that attackers were probing for common vulnerabilities rather than targeting specific application functionality + +**4.4 Importance of Categorization** + +This categorisation serves as a foundation for: + +* Understanding the **threat landscape** affecting the system +* Differentiating between **noise (scanner activity)** and **actionable threats** +* Supporting **safe and targeted tuning decisions** +* Ensuring that critical detection capabilities remain intact while reducing unnecessary log volume + +**5\. Detailed CRS Rule Analysis** + +This section provides a detailed analysis of the most frequently triggered CRS rules observed in the ModSecurity logs. Each rule is examined in terms of its purpose, behaviour in the environment, and security implications. The analysis also distinguishes between genuine attack attempts and noise generated by automated scanning. + +**5.1 Rule 913100 – Scanner Detection** + +* **Rule File:** REQUEST-913-SCANNER-DETECTION.conf +* **Category:** Scanner Detection / Reconnaissance +* **Description:** Detects known scanning tools based on User-Agent patterns +* **Observed Behaviour:** + * Triggered on requests targeting /cgi-bin/\* and other random endpoints + * Logs indicate User-Agent values such as security scanners (e.g., Nessus) +* **Security Interpretation:** + * Represents automated reconnaissance activity + * No direct exploitation attempt +* **Risk Level:** Low +* **Classification:** False Positive (Noise) +* **Action Recommendation:** + * Can be safely tuned for specific endpoints (e.g., /cgi-bin/\*) + * Should not be globally disabled + +**5.2 Rule 920270 / 920420 / 920440 / 920600 – Protocol Enforcement** + +* **Rule File:** REQUEST-920-PROTOCOL-ENFORCEMENT.conf +* **Category:** Protocol Validation +* **Description:** Detects malformed or non-compliant HTTP requests +* **Observed Behaviour:** + * Triggered by irregular or incomplete requests + * Often associated with automated scanning tools +* **Security Interpretation:** + * Indicates non-standard traffic patterns + * Common in bot-generated traffic +* **Risk Level:** Low +* **Classification:** Noise (Automated Traffic) +* **Action Recommendation:** + * Monitor but do not prioritise + * Can be selectively tuned if contributing to excessive noise + +**5.3 Rule 930100 / 930110 / 930120 – Local File Inclusion (LFI)** + +* **Rule File:** REQUEST-930-APPLICATION-ATTACK-LFI.conf +* **Category:** Local File Inclusion / Path Traversal +* **Description:** Detects attempts to access sensitive files using traversal patterns such as ../ +* **Observed Behaviour:** + * Requests containing paths like /etc/passwd, ../../ + * Often targeting /cgi-bin/\* endpoints +* **Security Interpretation:** + * Represents real exploitation attempts + * Likely automated but still malicious +* **Risk Level:** High +* **Classification:** True Positive (Attack Attempt) +* **Action Recommendation:** + * Must remain enabled + * Critical for protecting sensitive file access + +**5.4 Rule 932130 / 932160 / 932170 – Remote Code Execution (RCE)** + +* **Rule File:** REQUEST-932-APPLICATION-ATTACK-RCE.conf +* **Category:** Remote Command Execution +* **Description:** Detects command injection patterns and attempts to execute system commands +* **Observed Behaviour:** + * Triggered on suspicious input patterns within requests + * Often combined with other attack signatures +* **Security Interpretation:** + * Indicates attempts to execute arbitrary commands on the server + * High-risk attack category +* **Risk Level:** Critical +* **Classification:** True Positive (Attack Attempt) +* **Action Recommendation:** + * Must remain fully enabled + * Should not be tuned or relaxed + +**5.5 Rule 933135 – PHP Injection** + +* **Rule File:** REQUEST-933-APPLICATION-ATTACK-PHP.conf +* **Category:** PHP Injection +* **Description:** Detects malicious PHP code patterns in requests +* **Observed Behaviour:** + * Triggered in conjunction with /cgi-bin/\* probing +* **Security Interpretation:** + * Indicates attempts to exploit PHP-based vulnerabilities +* **Risk Level:** High +* **Classification:** True Positive +* **Action Recommendation:** + * Keep enabled + * Monitor for correlation with other attack patterns + +**5.6 Rule 941100 / 941110 / 941160 / 941390 – Cross-Site Scripting (XSS)** + +* **Rule File:** REQUEST-941-APPLICATION-ATTACK-XSS.conf +* **Category:** XSS +* **Description:** Detects injection of JavaScript or HTML into request parameters +* **Observed Behaviour:** + * Triggered by suspicious payloads containing script-like patterns +* **Security Interpretation:** + * Represents attempts to inject client-side scripts +* **Risk Level:** High +* **Classification:** True Positive +* **Action Recommendation:** + * Must remain enabled + * Essential for protecting web users + +**5.7 Rule 944100 / 944110 / 944130 / 944150 – SQL Injection (SQLi)** + +* **Rule File:** REQUEST-944-APPLICATION-ATTACK-SQLI.conf +* **Category:** SQL Injection +* **Description:** Detects database query manipulation attempts +* **Observed Behaviour:** + * Triggered by suspicious query patterns and payloads +* **Security Interpretation:** + * Indicates attempts to access or manipulate backend databases +* **Risk Level:** Critical +* **Classification:** True Positive +* **Action Recommendation:** + * Must remain fully enforced + * No tuning recommended + +**5.8 Rule 949110 – Blocking Evaluation (Anomaly Score)** + +* **Rule File:** REQUEST-949-BLOCKING-EVALUATION.conf +* **Category:** Anomaly Scoring +* **Description:** Evaluates cumulative anomaly score and determines blocking behaviour +* **Observed Behaviour:** + * Most frequently triggered rule in logs + * Activated when multiple suspicious patterns are detected +* **Security Interpretation:** + * Confirms that requests exhibit multiple attack characteristics + * Indicates effective detection by WAF +* **Risk Level:** Critical (Control Rule) +* **Classification:** System Behaviour (Not a False Positive) +* **Action Recommendation:** + * Must not be disabled + * Essential for WAF decision-making + +**5.9 Key Findings from Rule Analysis** + +* Majority of high-frequency alerts are associated with: + * /cgi-bin/\* endpoints + * Automated scanning behaviour +* Critical attack rules (LFI, RCE, SQLi, XSS) are actively detecting real threats +* Scanner detection and protocol enforcement rules contribute significantly to log noise +* Blocking evaluation rule (949110) confirms that multiple attack indicators are present within single requests + +**5.10 Summary of Rule Classification** + +| Type | Rules | Action | +| --- | --- | --- | +| Noise / Scanner Activity | 913100, 920xxx | Tune selectively | +| Real Attack Detection | 930xxx, 932xxx, 933xxx, 941xxx, 944xxx | Keep enabled | +| Core WAF Logic | 949110 | Do not modify | + +**6\. Security Impact Assessment** + +The analysis of ModSecurity logs and associated CRS rule triggers provides valuable insight into the security posture of the web application environment. By examining the nature and frequency of triggered rules, it is possible to assess both the types of threats targeting the system and the effectiveness of existing defensive controls. + +**6.1 Threat Landscape Overview** + +The observed rule triggers indicate that the system is exposed to a wide range of common web-based attack techniques. These include: + +* **Reconnaissance and scanning activity** + Identified through scanner detection rules, indicating automated tools probing the system for vulnerabilities +* **Local File Inclusion (LFI) attempts** + Evidenced by path traversal patterns such as ../ and attempts to access sensitive system files +* **Remote Code Execution (RCE) attempts** + Detected through command injection patterns aimed at executing arbitrary code on the server +* **Cross-Site Scripting (XSS) payloads** + Indicating attempts to inject malicious scripts into application inputs +* **SQL Injection (SQLi) patterns** + Suggesting attempts to manipulate backend database queries + +These attack categories represent some of the most critical and commonly exploited vulnerabilities in web applications. + +**6.2 Effectiveness of CRS Detection** + +The presence of multiple triggered rules across different categories demonstrates that the OWASP Core Rule Set is effectively identifying a broad spectrum of attack patterns. Key observations include: + +* **Multi-layered detection:** + Individual requests often trigger multiple rules across different categories, contributing to higher anomaly scores +* **Accurate classification:** + Rule messages and tags correctly identify the nature of the detected attack (e.g., LFI, RCE, SQLi) +* **Anomaly scoring effectiveness:** + The frequent activation of Rule 949110 confirms that the cumulative scoring mechanism is functioning as intended +* **Coverage of common attack vectors:** + The CRS provides comprehensive protection against widely known web vulnerabilities + +These findings indicate that the WAF is performing its primary function of detecting potentially malicious requests with a high degree of reliability. + +**6.3 Risk Evaluation** + +Based on the observed rule triggers, the following risk levels can be assigned: + +* **High to Critical Risk:** + * Remote Code Execution (RCE) + * SQL Injection (SQLi) + * Local File Inclusion (LFI) + These attacks have the potential to compromise system integrity, access sensitive data, or gain unauthorised control over the application +* **Medium Risk:** + * Cross-Site Scripting (XSS) + These attacks primarily affect client-side security but can lead to session hijacking or data theft +* **Low Risk:** + * Scanner detection and protocol violations + These represent reconnaissance activity and malformed traffic rather than direct exploitation + +**6.4 System Security Posture** + +From the analysis, the overall security posture of the system can be summarised as follows: + +* The application is actively being targeted by automated tools attempting common exploitation techniques +* There is **no evidence of successful exploitation**, as requests are intercepted and identified by the WAF +* The WAF, powered by ModSecurity and CRS, is effectively detecting and evaluating malicious traffic +* Critical attack detection rules are functioning correctly and contributing to anomaly scoring and potential blocking decisions + +**6.5 Key Insights** + +* The system is exposed to **continuous background noise from internet-wide scanning activity**, which is typical for publicly accessible web services +* The CRS rules provide **broad and effective coverage** of known attack vectors +* The anomaly-based detection model ensures that even complex or multi-stage attacks are identified +* The presence of repeated attack attempts highlights the importance of maintaining an active and well-configured WAF + +**6.6 Summary** + +The security impact assessment confirms that the current WAF configuration is successfully detecting a wide range of web-based threats without evidence of compromise. The combination of comprehensive rule coverage and anomaly scoring ensures that potentially malicious requests are identified and evaluated effectively. + +This demonstrates that the deployed security controls are robust and capable of defending against common attack techniques, providing a strong foundation for maintaining application security. + +**7\. Recommendations** + +Based on the analysis of CRS rule behaviour and observed security events, the following recommendations are proposed to maintain and enhance the effectiveness of the Web Application Firewall (WAF) deployment. + +**7.1 Maintain Critical Detection Rules** + +Rules associated with high-risk attack categories must remain fully enabled without modification. These include: + +* Local File Inclusion (LFI) – REQUEST-930 +* Remote Code Execution (RCE) – REQUEST-932 +* Cross-Site Scripting (XSS) – REQUEST-941 +* SQL Injection (SQLi) – REQUEST-944 + +These rules are essential for detecting and preventing exploitation attempts that could compromise system integrity or data confidentiality. + +**7.2 Preserve Anomaly Scoring Mechanism** + +The anomaly scoring system, particularly Rule 949110, plays a critical role in evaluating cumulative threat levels within requests. It is recommended that: + +* The anomaly scoring logic remains unchanged +* Blocking thresholds are carefully maintained +* No direct modifications are made to core evaluation rules + +This ensures consistent and reliable decision-making within the WAF. + +**7.3 Monitor Scanner and Protocol-Based Rules** + +Rules related to scanner detection (REQUEST-913) and protocol enforcement (REQUEST-920) should be continuously monitored, as they provide visibility into reconnaissance activity and abnormal traffic patterns. + +While these rules may contribute to higher alert volumes, they are valuable for: + +* Identifying scanning trends +* Understanding exposure to automated tools +* Supporting threat intelligence analysis + +**7.4 Implement Controlled and Scoped Tuning** + +Where necessary, tuning should be applied in a controlled and targeted manner. Any optimisation must: + +* Be limited to clearly validated non-critical patterns +* Avoid disabling entire rule categories +* Preserve detection capability for genuine threats +* Be tested and validated before deployment + +This approach ensures that noise reduction does not weaken the overall security posture. + +**7.5 Continuous Monitoring and Review** + +WAF effectiveness depends on ongoing monitoring and periodic review. It is recommended to: + +* Regularly analyse ModSecurity logs +* Track changes in rule frequency and attack patterns +* Reassess tuning decisions over time +* Update rule configurations as the application evolves + +**7.6 Documentation and Knowledge Sharing** + +Maintaining clear documentation of CRS rule behaviour and tuning decisions is essential for operational continuity. This includes: + +* Mapping Rule IDs to attack categories +* Recording tuning actions and justifications +* Sharing insights across the security team + +This ensures that future team members can understand and maintain the WAF configuration effectively. + +**7.7 Summary** + +The current WAF configuration demonstrates strong detection capabilities across multiple attack categories. By maintaining critical rules, applying controlled tuning, and continuing regular analysis, the system can achieve an optimal balance between **security effectiveness and operational efficiency**. + +**8\. Conclusion** + +This documentation presented a structured analysis of CRS rule behaviour within a ModSecurity-based Web Application Firewall deployed in the Redback Operations environment. By systematically mapping Rule IDs to their respective categories within the OWASP Core Rule Set, the study provided clear insight into how different types of web-based attacks are detected and evaluated.The analysis demonstrated that the WAF, powered by ModSecurity, is effectively identifying a wide range of attack patterns, including Local File Inclusion, Remote Code Execution, Cross-Site Scripting, and SQL Injection. The anomaly scoring mechanism further reinforces this detection by aggregating multiple rule triggers to assess the overall threat level of each request. + +Importantly, the findings highlight that while a significant volume of alerts is generated, the underlying detection mechanisms are functioning correctly and provide comprehensive coverage against common web vulnerabilities. The categorisation of rules and interpretation of their behaviour enables a deeper understanding of the threat landscape and supports informed decision-making in WAF management. + +Overall, this work establishes a strong foundation for maintaining an effective and resilient web security posture. By combining accurate rule analysis, continuous monitoring, and structured documentation, the organisation can ensure that its WAF remains both robust against real-world attacks and adaptable to evolving security requirements. \ No newline at end of file