Editor’s note: In our previous blog post, we announced that Wiz was expanding its risk assessment capabilities beyond cloud infrastructure by now including host and application configuration analysis, without the need of an agent. This blog dives deeper into customizing host configuration rules.
Modern large scale application infrastructures equate to larger probabilities for misconfigurations. Many organizations also have wider arrays of applications and operating systems, different compliance requirements across multiple organizations, and require specialized operation teams to manage all of it. Consequently, it becomes complicated to answer simple questions about your infrastructure:
How can I easily query all my assets for files and settings?
What applications are configured on my hosts, and are they compliant with organization standards?
Are my deployments consistent or have they evolved over time through manual intervention?
Investigating and answering these questions manually is possible, but it is far too time-consuming and resource intensive for quality results at scale. In smaller scale or development environments, this would suffice. However, in larger production environments, no security operations team would manually run shell commands on hundreds of production workloads.
There are also plenty of traditional configuration management tools available to help you answer these questions well, but often with some caveats:
An agent needs to be deployed, which can be resource intensive and require updates and management
If an agent is not required, alternatives often still require network connection through ssh and/or winrm
They require use of privileged users/service accounts, increasing risk for account takeover if agents are compromised
Left limited to auditing only the servers where agents are deployed on, leaving gaps in visibility
As you can see, the market needs a better solution.
Revealing the misconfigurations and detecting drifts
Wiz ships thousands of predefined rules to cover broad visibility into auditable configuration issues and fulfill external compliance requirements. Wiz’s custom host configuration rules takes a different approach: allow Wiz users to create their own custom rule logic to execute during our agentless workload scans.
By allowing custom rules to be created, users do not need to run manual commands on virtual machines or application configuration files to determine configuration state. This enables full coverage across the cloud estate without the need to deploy an agent or sidecar to a running production workload. On any new workload, Wiz assesses your custom rules and automatically determines if the application or OS is misconfigured. Over time, if configuration state changes due to user intervention and/or malicious intent, Wiz will be there to audit the changes and alert you when there is configuration drift. To top it off, Wiz will then be able to generate useful findings for infrastructure and application teams to remediate the misconfiguration. Sounds great, but how does it work?
At Wiz, we often describe custom host configuration rules as using a metaphorical magnifying glass to investigate your workload’s content. Virtual machines are black boxes that may have applications with misconfigurations. Custom rules reveal these misconfigurations and allow you to zoom in on configuration without having to scope into a specific resource.
Wiz provides the capabilities to run multiple test cases on your hosts, such as file content parsing, DPKG information probing, and OS configuration testing. If required, users can also run multiple tests within a single rule. Wiz allows to apply these criteria across several hosted apps and operating systems at once, so users don’t have to copy-paste each rule to fit a single operating system or application.
We’ll review an example to demonstrate how painless creating a custom host configuration rule is.
In our example, let’s check for Nginx installations that have `merge_slashes` directive disabled. Leaving this setting to “off” can lead to a directory traversal vulnerability. There are 3 main steps to generating the rule:
1. Selecting your target platform: Wiz provides the option to select multiple applications and/or operating systems, called target platforms. Systems running that specific technology will have the rule run against them and only them. In this case, we will select Nginx only, but it can apply this to entire operating systems as well. Wiz will soon also add the ability to target all hosted technologies detected on VMs as well.
2. Generating your rule definition: For the rule to evaluate, we need to write our own custom logic. Wiz uses a simplified OVAL schema called Direct OVAL language for rule definition. Each rule is represented by an official OVAL schema test and conditions between them to determine the expected assessment results. In our example case, we include a single criterion and set the test to `textfilecontent54_test`, configuring `check=”all”` to check the entire virtual machine directory for our file. We then need to specify the file we want to interrogate, in this case `/etc/nginx/nginx.conf`. Last, we add the pattern in the object we are parsing. This is the equivalent of performing a `grep` shell command on the file, but instead of `grep`, we use regex. Here, we use the pattern `.*merge_slashes.*on;.*`
<definition xmlns="https://wiz.io/XMLSchema/direct-schema">
<criteria operator="and">
<criterion>
<textfilecontent54_test check_existence="at_least_one_exists" check="all" comment="Ensure at least one file named /etc/nginx/nginx.conf exists and matches pattern .*merge_slashes.*on;.*">
<textfilecontent54_object comment="Ensure at least one file named /etc/nginx/nginx.conf exists and matches pattern .*merge_slashes.*on;.*">
<filepath>/etc/nginx/nginx.conf</filepath>
<pattern operation="pattern match">.*merge_slashes.*on;.*</pattern>
<instance datatype="int">1</instance>
</textfilecontent54_object>
</textfilecontent54_test>
</criterion>
</criteria>
</definition> 3. Configuring rule metadata: To make the rule unique and identifiable, we add a rule name with an optional rule description. We also allow the setting of a severity based on your organization’s policies, ranging from low to critical. Finally, we allow users to associate the rule to either built-in compliance frameworks or custom frameworks.
After evaluation, we can see that findings are generated for each machine that has failed the rule. Each host configuration can be seen in the Configuration tab for each machine, so you can quickly identify all host configuration issues for your machines as well.
Using Wiz’s custom host configuration rules help provide that missing detection and visibility on those critical host configuration issues. As long as you know your desired parameters, writing custom rules is as easy as it seems. If you are new to writing OVAL rules, don’t fret; Wiz has many guides on how to write custom host configuration rules. You can learn more in the Wiz docs (login required). Contact Wiz to learn more and get a demonstration on how to connect your environment within minutes.
