How SAP Advisories Affect You
This week you will have seen from our twitter account, (@Onapsis) or other security news feeds like PacketStorm regarding the publication of information about six advisories discovered by the Onapsis Research Labs effecting SAP. In a past blog, Securing Your SAP Through Research, I talked about the importance and value of the security research we do here at Onapsis. Additionally, I have discussed the fact that we have seen automated, widespread attempts to compromise SAP systems as well as very targeted attacks and the implications of those attacks.
If you look at the latest six advisories released by the Onapsis Research Labs which are listed on our advisory page you will see they impact across a variety of SAP technologies that have very different delivery methods. There are three vulnerabilities effecting SAP HANA, two targeting the Extended Application Services (XS); one of which is XSS in the Administration Tool for SAP HANA XS and the third is an authentication bypass. A highlight for me was the discovery of a hardcoded user in SAP FI Manager Self-Service, which effects every installation of FI Manager.
It is very important that you stay informed by reading about the advisories we publish and also the monthly Security Notes releases by SAP and that you evaluate their relevance to your critical systems and the risk they represent to those critical systems.
As I engage with our customers I am often asked “What process does Onapsis follow when delivering the security advisories to the market?” Onapsis Research Labs follow the principles of responsible disclosure plus SAP’s stricter publication requirements. As such, at SAP's request, we wait three months from the publication of a Security Note by SAP before we publish our technical details related to that note. The intention is to provide SAP customers a window of time to apply the note before the technical details become ‘widely’ known (this assumes that no-one with access to SAP notes are circulating that information). When we do complete those requirements and publish, that extra level of technical information is published directly on our Onapsis website.
In any security mature organization one of the ongoing tasks of the security team is to report to the CIO, CSO and/or CFO the current state of risk to business operations due to the security state of the technology employed. With a regular (second Tuesday of every month) security note release cycle by SAP the security team within the organization should be able to (and be expected to) refresh the currently known security and risk posture of their SAP systems, and the subsequent risk to the business data and processes that rely on or pass through those systems, every month.
It is no longer acceptable to use the results of last year’s SAP audit as the basis of determining the current state of the risk to your SAP systems today. Given this monthly cycle of release of SAP’s Security Notes and Risks we know the accuracy of our knowledge of the risks and vulnerabilities in these systems deteriorates each month. The only way to achieve an acceptable degree of accuracy is to apply the best practices we have learned in our network vulnerability management process and to perform a monthly assessment of the risk inherent in our SAP systems.
In view of the above doesn't it seem logical that the reevaluation of risk levels for SAP systems would also be monthly? Even in an environment where SAP Notes are only applied on a quarterly or half yearly schedule the gaining of a consistent and more frequent review of the risks that exist in a given SAP system still allows the various security teams to understand how the most likely successful attack would occur; thus allowing your defense in depth or your adaptive defense strategies to work much more efficiently and at your companies cadence of vulnerability scanning as well as incident management processes.