By now I am sure you have seen the public posting with details and a how-to guide regarding an exploitable SAP vulnerability in a major organizations’ internet facing website. It is always disheartening to see a company exposed in this way. It is a cliché (though truth be told I tend to think clichés have an element of truth to them) but when I read about this type of event and the recent Target breach I look for the teachable moment or lessons I can learn. Good security is an ounce of prevention and a dash of luck, and the more you can learn about appropriate preventions the less luck you will need.
When thinking about this event I actually thought of five teachable elements I can use to provide support for my security approach and philosophy. I wanted to start a discussion about SAP and security, something which has only recently been discussed, and review the silent points from what has occurred thanks to the Full Disclosure posting and WooYun report from the Chinese hacker known as Finger.
This event touches on a couple important areas:
- Responsible disclosure
In the posting they cite the date 2013-11-21 as when they submitted a report to the vendor and 2014-01-05 as the date they published the details of the vulnerability and how to exploit it on NVIDIA’s servers, despite the vulnerability not having been addressed, due to a lack of a response. This is less than two months (during a busy holiday season) and it is unclear how many times they attempted to contact the security team. While I agree that it is important to get vulnerability information public so issues can be addressed I think it is more important to do so responsibly. Typically attackers/cyber criminals have less change control processes to go through and can weaponize and take advantage of this information long before organizations have been able to test and apply the remediation across their environment. In fact Mariano Nunez, Onapsis CEO, has said “It is critical when you have information that could cause harm to companies effected that you make best efforts to ensure that information is communicated to those companies along with the information needed to remediate those issues before making that information publicly known.”
Onapsis experts were the first ones to engage with SAP’s Product Security Response Team by responsibly reporting critical security vulnerabilities in SAP applications, helping SAP provide security patches to customers since 2006.
- Time to Patch
In this instance the vulnerability was disclosed and a patch for it was released by SAP in 2011. The fact that this vulnerability is still present on a public facing server is a concern. As Juan Perez-Etchegoyen, Onapsis CTO, has said “It is important to have a process in place whereby you review patches and vulnerabilities released by vendors of systems you rely on and a process to implement those patches. Hopefully in this case it is a matter of a patch not being applied properly, and the validation to the patch application not being done, rather than no patching efforts being undertaken.” While the fact that every month, without fail another batch of patches is released may sometimes make you feel like Sisyphus it is important to keep in mind that this work is important to the cyber health and safety of an organization’s systems. And as such it is vitally important to have a process whereby critical patches, notes and vulnerabilities released are identified quickly and addressed in a timely manner. This identification process is complex and time intensive, and something we as a company invest a lot of our resources into each month. Because we consider this understanding to be critical for all SAP customers we are pleased to take this opportunity to announce we will be providing a monthly summary of the SAP Security Patch Day via this new series of blogs; providing yet another free, educational and valuable resource for SAP customers to ensure they are making the best security decisions regarding their SAP investment.
- Regular self-assessment
Best practices (as defined by public standards and organizations) for businesses is to scan their systems frequently, with the frequency of the scans increasing as the systems to be scanned rise in criticality to the business or their accessibility from the internet increases. Patches not applying properly for one reason or another does happen, and regular scanning is designed to identify when this happens and alert the organization to this risk. However, as I have mentioned elsewhere organizations sometimes make the mistake of thinking their general purpose security scanners and tools are reporting on specialized systems like SAP. But this scenario is a highlights why SAP certified the Onapsis X1 product to perform vulnerability assessments and audits of SAP systems – because auditing and identifying issues in these systems is a specialized activity and requires specialized tools.
- Misunderstanding the importance of SAP security
This scenario illustrates one I have debating with others for some time now – the claim that being ignorant of a vulnerability means you are not responsible for remediation or fro any damages resulting from its exploitation. If this vulnerability had not been published but instead leveraged by cyber criminals and caused damages, would the organization in question be liable? Could their cyber insurer claim they had been negligent and therefor not eligible for cover? The vulnerability has been known since 2011 and commercial tools such as Onapsis X1 exist to detect the presence of this issue (and thousands more). So could they have claimed a defense of being ignorant to the vulnerability and therefore not at fault for not addressing it and preventing the breach? More and more security experts are siding now that vulnerability assessments and auditing are standard practice, and the failure to perform these practices (correctly) is negligence.
- Compliance vs Security
There is a good chance that this company passed their SAP audits with flying colors. The reason is historically audits have concentrated on Segregation of Duties (SoD) – checking if users have permissions and rights beyond the needs of their role within the organization. While important these audits do not check for the presence of these types of vulnerabilities (which allows for a non-user to gain control of the system) or validate that the organization is regularly checking for these types of vulnerabilities.
I recognize this last section is potentially inflammatory, not because it is wrong, but because the amount of effort needed to change from the status quo and for organizations or auditors to broaden their efforts around SAP to look for these vulnerabilities. Interestingly the auditors are taking the lead in this area; you only need to look at the recent press releases regarding the major audit firms announcing their partnership with Onapsis and their bringing on-board of our leading Onapsis X1 technology to see the intention of auditors. No auditor wants to be the one who gave someone an A+ only to see them breached via a known vulnerability in the SAP Framework a few weeks later.
At Onapsis we have performed SAP Penetration Tests against more than 3,000 SAP servers, and in every single case, the systems were “compliant”. However, in virtually all cases, our experts could show that attackers were able to carry out espionage, sabotage and fraud attacks without the need for a valid user account on the target system, simply by exploiting low-level SAP cybersecurity vulnerabilities. The status quo is no longer sustainable.
It is unfortunate that these events happen, and I believe you can never take a holier than thou attitude as we are all that dash of bad luck away from an event happening to us. But we can take this as an opportunity to review what we are doing to measure the security of our SAP systems and decide if we are comfortable with the efforts and frequency in place. And if you are not, well, as always I am happy to show you the first and most widely-used automated SAP security assessment solution…