Mitigating your third-party exposure to Apache Struts2 requires accurate, actionable data -- and fast. If you can apply automated techniques to rapidly identify which of your vendors are most likely exposed to the exploit, you can quickly prioritize your risk resources and engage constructively with impacted vendors.
Gain Third-Party Exposure Visibility
Creating a comprehensive view of your third-party potential exposure to threats such as Struts2 may seem an insurmountable task. The default approach is to send a questionnaire to each of your hundreds of vendors when an incident occurs, asking them to attest to their exposure and remediation.
Using innovative techniques developed by RiskRecon, you can maintain objective awareness of your third-party exposure that does not require vulnerability scanning or other invasive techniques. For example, systems running a Java Application Server are potentially exposed to the Struts2 vulnerability exploit. This information can be gathered automatically through passive interaction with each of the vendor’s web applications. Sources of relevant information include:
- HTTP Set Cookie Header will reveal use of Java where JSESSIONID is present
- HTTP X-Powered-By Headers reveal the presence of Java through values such as Servlet 2.4, JSP 2.0, GlassFish, or JBoss
- URL file extensions indicative use of Java include “action,” “.do,” and “.jsp”
Thus, if you have the means to rapidly map your vendors' IT footprints and passively observe these software configurations, you can combine this knowledge with robust analytics to rapidly identify potential security exposure.
With good data, you can quickly prioritize your risk mitigation efforts towards those potentially exposed vendors running Java Application Servers. While other vendors should not be ignored, vendors with known potential exposure should be given high priority.
Based on RiskRecon’s measurements, approximately 36% of the high-risk vendors serving the Fortune 500 are potentially exposed to Apache Struts2 on the internet, running at least one publicly-accessible Java Application Server.
Conduct Vendor Validation
Structured correctly, vendor responses to your questionnaire can be validated against objective data to determine which potentially exposed vendors are correctly mitigating the risk. Consider the following question set:
Question 1) How many systems in your environment are running Java Application Servers on Apache that are potentially exposed to the Struts2 exploit? Please describe the process of identification.
Question 2) If potentially vulnerable systems were identified, how many of the identified systems were vulnerable to Struts2 exploit? Please describe the process of vulnerability testing.
Question 3) Of the vulnerable systems identified, how many have been patched?
Now you can compare each vendor’s questionnaire answers with the data gathered by passively interacting with their Internet systems. For example, if a vendor responds to Question 1 stating they have no potential exposure but your assessment shows their running numerous internet-based with Java Application Servers, you can initiate escalation procedures with them.
Similarly, if a vendor’s response indicates they have identified 10 potentially exposed systems and your data identified five potentially exposed systems then you can have high confidence that they are properly managing the situation.
Even better results can be obtained by building a relationship with your vendors through which you can share your threat intelligence. In the process, you may provide the vendor knowledge of potential exposures they overlooked. Perhaps more importantly, the vendor will know you are in the fight together. After all, who better to share intelligence with than those vendors with whom you’ve entrusted with your assets?
The Right Results
Absent good, verifiable data on your vendors' potential risk exposure, you are left to blindly approach each of your partners with the same attestation request and you are unable to proactively help your vendors protect your assets.
On the other hand, good data on your vendors' potential risk exposure shared in a constructive relationship allows you to prioritize your risk mitigation resources and assist your vendors in the fight. It also serves as fuel to build stronger security relationships with your vendors that will be mutually beneficial. Rather than fostering an environment of suspicion, assessing and sharing information about the environment’s realities will foster trust. Trust, but verify. And collaborate.
RiskRecon enables enterprises to see beyond the limitations of periodic questionnaires to their third-party risk reality. RiskRecon brings to bear deep, accurate security transparency and actionable measurements for every enterprise, enabling organizations to continuously manage their third-party risk reality at scale.
Within hours of the Apache Struts exposure, RiskRecon accelerated their customers threat response by providing actionable intelligence about their potential exposure in their own enterprise and third-party IT assets. Let’s discuss how you can strengthen your third-party relationships with our innovative assessment and collaboration solutions.