There is a high number of third-party solutions in the SAP universe. Unfortunately the number of vulnerabilities in these solutions is even higher. Here are some lessons learned.
Companies conducting risk assessment projects, continuous monitoring or internal security QA will sooner or later come across vulnerabilities in third-party solutions. In order to gain access to a proper patch in a timely manner, these vulnerabilities have to be reported to the vendor in a responsible way, paired with the intention of achieving fast results.
While some vendors react very fast, professional and supportive, others try to engage you in endless discussions and meetings in an attempt to downplay the issue.
More than once vendors were not happy about bug reports and tried to argue that there is actually no risk or that this behavior is actually a feature or that someone else tested their product and found no issues or that the issue is totally exaggerated, etc etc.
In order to not waste internal resources with technical discussions, it is often helpful to have the security experts that found the vulnerabilities also create the corresponding security advisory for the issue and engage in direct communication with the vendor to handle all questions, doubts and complaints. In our experience, the most effective approach is for the expert who identified the issue to create the advisory in the name of the affected company. This convinces vendors to take the matter seriously and provide a timely patch, while protecting companies from detailed technical discussions and repeated meetings with the vendor.
In any case, should your company decide to handle such issues independently, we recommend providing the following comprehensive information in security advisories for SAP add-on providers:
1. A concise title that clearly describes the issue. E.g. "Remote Arbitrary File Deletion by $VENDOR $TOOL"
2. A unique ID to refer to the issue
3. Include a version and a date. You may wish to update the contents based on new insights or feedback from the vendor.
4. A CVSS vector. Although CVSS is not ideal for describing SAP risks, it is an industry standard and a good indicator of risk.
5. The names / versions of the affected add-on, ideally also the vendor's transport request ID
6. A brief, high-level summary of the vulnerability and its associated risk.
7. A detailed explanation of the risks, including evidence, and a step-by-step guide on how to conduct a potential attack. Ideally, this should include screenshots.
8. A recommendation on how to mitigate the vulnerability. Some add-on vendors lack an in-depth understanding of SAP security risks and best practice solutions.
9. Ideally, a full copy of the source code responsible for the vulnerability should be provided, with the problematic lines highlighted.
10. A version history
11. Contact information, ideally paired with a secure communication channel such as a link to a PGP certificate.
12. A reference to your Responsible Disclosure Policy. This policy outlines how your company handles vulnerabilities in external solutions and sets out timelines for the public disclosure of vulnerabilities.
This is the third article in our SAP Add-on series that provides you with insights into risks related to running third-party solutions as well as defensive strategies.If you'd like to know more about SAP Add-on risks, please contact us. Understanding these risks helps in making informed decisions about which third-party solutions to adopt and how to manage them securely.
