Full Report
Shell commands that once had to be run manually now can be coded into a custom rule and run daily using Wiz agentless workload scanning.
Analysis Summary
# Best Practices: Agentless Host and Application Configuration Auditing
## Overview
These practices focus on leveraging agentless scanning capabilities (like custom host configuration rules) to gain broad visibility into host and application configuration states, detect misconfigurations, and identify configuration drift across cloud assets without deploying resource-intensive agents or relying solely on traditional network-based access (SSH/WinRM).
## Key Recommendations
### Immediate Actions
1. **Deploy Agentless Scanning Capability:** Immediately enable and configure the agentless scanning solution covering all cloud workloads to gain baseline visibility into host and application configurations.
2. **Utilize Predefined Rules:** Leverage the thousands of predefined configuration rules provided by the platform to cover broad visibility into known auditable configuration issues and initial compliance fulfillment.
3. **Establish Initial Compliance Scope:** Identify the most critical existing compliance requirements and ensure the relevant predefined rules are activated against the appropriate asset groups.
### Short-term Improvements (1-3 months)
1. **Define Custom Security Baselines:** Document organizational standards for critical applications (e.g., Nginx setup, specific OS hardening parameters) not covered by standard compliance checks.
2. **Develop Custom Host Configuration Rules (HCRs):** Begin creating custom rules using the simplified OVAL schema (Direct OVAL language) to check for organization-specific security hardening parameters (e.g., disabling vulnerable directives like `merge_slashes` in Nginx).
3. **Targeted Platform Application:** Configure custom rules to target specific applications or Operating Systems (Target Platforms) rather than applying blanket checks, ensuring rules only scan relevant hosts.
4. **Configure Severity and Metadata:** Assign appropriate severity levels (Low to Critical) to all custom rules and associate them with internal tracking frameworks for effective prioritization.
### Long-term Strategy (3+ months)
1. **Implement Configuration Drift Monitoring:** Establish ongoing scans to automatically detect and alert on configuration state changes (drift) caused by manual intervention or malicious activity post-initial deployment.
2. **Integrate Findings into Remediation Workflows:** Ensure that configuration findings generated by custom rules are seamlessly integrated into existing ticketing or infrastructure management systems for timely remediation by infrastructure and application teams.
3. **Regular Rule Review and Expansion:** Periodically review the effectiveness of existing custom rules and expand coverage to address newly deployed technologies and evolving security threats.
4. **Maintain Rule Documentation:** Document the rationale, scope, and expected OVAL logic for all custom rules, maintaining easily accessible references for new security staff.
## Implementation Guidance
### For Small Organizations
- **Prioritize Critical Assets:** Focus initial custom rule development strictly on the application configurations posing the highest risk to the organization or those hosting the most sensitive data.
- **Leverage Basic Rule Structures:** Start with simple file content parsing (`textfilecontent54_test`) and direct permission checks, relying heavily on built-in guides for OVAL basics.
- **Manual Remediation Tracking:** Use the generated findings reports directly to assign remediation tasks manually until automated integration pipelines are established.
### For Medium Organizations
- **Establish Rule Ownership:** Assign specific teams or individuals responsibility for writing, validating, and maintaining rule sets for different technology stacks (e.g., one owner for Linux OS checks, another for application server configurations).
- **Implement Multi-Dimensional Targeting:** Utilize the ability to target rules based on multiple operating systems or application types simultaneously to maximize efficiency without duplicating rule logic.
- **Integrate with Asset Inventory:** Ensure the configuration scanning output is cross-referenced with the existing asset inventory to maintain an accurate picture of configuration compliance per business unit or environment.
### For Large Enterprises
- **Develop Standardized OVAL Templates:** Create organizational templates for common test types (e.g., configuration file validation, user account auditing) to enforce consistency across custom rules.
- **Framework Alignment at Scale:** Map custom rules rigorously against multiple internal and external compliance frameworks simultaneously to satisfy diverse organizational requirements efficiently.
- **Automated Finding Ingestion:** Implement API/platform integrations to automatically ingest findings into central SIEM, SOAR, or Configuration Management Database (CMDB) systems for automated triage and workflow automation.
- **Restrict Rule Creation Permissions:** Implement strict role-based access control (RBAC) around who can define and deploy custom HCRs to prevent accidental deletion or deployment of erroneous logic across the estate.
## Configuration Examples
**Goal:** Audit Nginx configurations to ensure the `merge_slashes` directive is set to `on` to mitigate potential Path Traversal vulnerabilities.
| Step | Configuration Detail | Example Value/Action |
| :--- | :--- | :--- |
| **1. Target Platform** | Select specific applications/OSs where Nginx runs. | Nginx (Applicable OSs) |
| **2. Rule Definition (OVAL Logic)** | Test Type: `textfilecontent54_test` | `check="all"` |
| **File Path** | Location of the configuration file to examine. | `/etc/nginx/nginx.conf` |
| **Pattern (Regex)** | The required pattern indicating compliance. | `.*merge_slashes.*on;.*` |
| **3. Metadata** | Rule Name and Severity. | Name: `Nginx_MergeSlashes_Enabled`; Severity: Critical |
## Compliance Alignment
- **NIST CSF:** Identify, Protect (Focus on Configuration Management and Access Control baseline enforcement).
- **ISO 27001/27002:** A.12.2 (Change Management) and A.14 (System Acquisition, Development, and Maintenance - ensuring secure configurations).
- **CIS Benchmarks:** Directly supports the validation of specific configuration controls defined within technology-specific CIS Benchmarks (e.g., ensuring insecure settings are disabled).
## Common Pitfalls to Avoid
1. **Over-reliance on Manual Shell Commands:** Do not attempt to manually verify configurations on production hosts (via SSH/shell) as this does not scale and creates significant operational risk.
2. **Agent Deployment Overhead:** Avoid solutions that necessitate deploying, patching, and managing agents on every production workload, as this introduces performance overhead and new security surface areas.
3. **Using Overly Broad Regex:** Writing regex patterns that are too general can lead to excessive false positives or, conversely, mask required security directives if the pattern is too restrictive.
4. **Ignoring Configuration Drift:** Failing to continuously scan for changes after initial baseline configuration acceptance means vulnerabilities may be reintroduced silently over time.
5. **Using Privileged Accounts for Scans (If using agent/network alternative):** Avoid leveraging highly privileged or domain admin accounts for traditional scanning methods, as compromising these credentials significantly raises the risk profile.
## Resources
- **Organizational OVAL Writing Guides:** Refer to vendor-specific documentation regarding the structure and accepted OVAL schema variations for custom rule creation.
- **Security Community Resources:** Consult OWASP guides (e.g., for Path Traversal) to inform the development of rules targeting known application vulnerabilities.
- **Vendor Documentation:** Utilize platform-specific guides on basic OVAL construction and targeting logic (e.g., documentation sections titled "Writing Custom Host Configuration Rules" or "OVAL Basics").