When a new vulnerability is discovered in Apache Struts I am often asked by our customers, “Can I create a Firewall Policy in Nexus IQ Server to block all versions of Struts except for ones approved by our security team?”  This is absolutely something that you can do, however it may not be the best solution to the problem.

A Better Way

A better option would be to configure your security policy based on the actual vulnerabilities found in components rather than manually managing the blacklist provided by your security team.  This way, when new vulnerabilities are discovered on components, even the ones on your security whitelist, Nexus Lifecycle’s Continuous Monitoring will report the violations quicker than your security team could update their whitelist.  From the component info panel in the scan report, your developers will either know exactly which version they will need to move to or they can drill into the vulnerability details provided by our security team to learn the best course of action.

So now that we know the better way, we still need to figure out a way to work with the mandate from management after reading the recent news headline or blast from a security vendor.  No worries, we can still do this, so let’s jump into the policy.

Policy Scope

To quarantine components at your proxy repository using Nexus Firewall, you will need to create your policies at the Root Organization level and set the scope to All Applications and Repositories.  If this is just for an application scan, you can create the policy at any level that makes sense. Even better would be setting an Application Category to select the applications that this policy should apply to.  This way, you are sure to flag Struts on your mission critical sites.

Policy Conditions

To pinpoint the Struts components we are looking for, we will need to use Coordinates as our matching condition.  For the maven GAV we will use “org.apache.struts” and the Artifact as “struts*” with the asterisk wildcard to find all of the components that make up Struts.  The other three options are the Version, the Extension, and the Classifier. In this case, we just wanted the components in the 2.3.x range, so we will suffix the Version “2.3.*” with another asterisk wildcard.

Whitelisting Versions

Next we want to add another condition for the “approved” versions of Struts.  This works by switching the “match” condition to “do not match” and requiring that “all” conditions must be true.  When scanning this specified version of 2.3.35, this condition will match; resulting in an overall false statement and not tripping up the policy.

Additional Ranges

We can add additional version ranges by adding more Constraints with its own range and whitelisted versions. These additional constraints are treated like the any option -- as long as one of them is true, it will violate the policy.   You are not limited to a single whitelisted component, however each specific version will need to be added as a separate condition.

In Closing

Remember, this doesn’t mean that there are not security vulnerabilities on these whitelisted components, only that these versions don’t fail our mandated architectural policy.  Also keep in mind that newer versions of the Struts component would also fail this policy until you update your whitelist. For now, there isn’t a “greater than” option so we recommend adding the versions as they become approved.  Using architectural policy to gate the components for your organization is an important use-case for Nexus Firewall. However, we recommend using security policies backed by the timely data available from our research team to manage your security vulnerabilities in real-time.