I spent this morning reviewing materials about Oracle’s Security in Silicon. Well, in general, the idea to secure a platform from a low level makes sense. But to do so we need to design the hardware from the scratch, new type of OS for it, and so on. All these things must be completely redesigned to prevent architecture design vulnerabilities such as buffer overflow.
According to the official press-release and as far as I understand, this chip just accelerates encryption – that’s useful, but it doesn’t prevent cyberattacks. It somehow prevents access to data in Memory. Well, probably it will make buffer overflows much harder to exploit. It’s a significant improvement, but there is nothing related to application security. An XSS vulnerability in new cloud application still stays an XSS vulnerability, no matter what kind of chips, OS or Virtual platform of Database you use. It’s all on the application layer which happens to be the most important aspect nowadays.
If you want to build a new secure platform from scratch starting with a microchip, you need to build new hardware, OS, and Application layer, you need to invent COMPLETELY new programming language, free from application errors, new frameworks, etc… It’s a great idea (of course, nobody can be sure that this new architecture will be without new bugs, but that’s another story). When you highlight that now Oracle is secure and the most important feature is fast encryption, and you introduce a new chip leaving the rest of the things almost unchanged, it’s nothing but a good marketing campaign.
The second feature from “Security in Silicon” presented by Oracle is Silicon Secured Memory. I would be hard to comment until I try it, but as far as I’m concerned, it may introduce better security from Buffer overflow vulnerabilities. All these enchantments don’t prevent vulnerabilities that were identified by our interns in Oracle ERP system recently such as XSS Vulnerability, SQL Injection vulnerability (well, as for SQL Injection we will still need to go over it before we can say it with a 100% certainty), several XXE Injection Vulnerabilities (, ), and User Enumeration vulnerability., as well as an older vulnerability in Oracle PeopleSoft which affects hundreds of organizations worldwide.
P.S. Some thoughts about moving to cloud and Security
When app is in the cloud, the cost of failure can be tremendous.
If there is a vulnerability in on-premise solution, let’s say in complex Legacy ERP System, cybercriminals need to find a way to access a company’s network to exploit this vulnerability. It’s quite easy to find an issue in this kind of systems since they were developed in a generation when nobody cared about cybersecurity threats.
If there is a vulnerability in Cloud system, it’s much easier to exploit it. Cybercriminals don’t need to think how to get access to a company’s network, one exploit can have a cascading effect on all companies. But on the other hand, new cloud solutions are definitely more secure by design, as they were only developed recently when there already was a much higher security awareness.
But in addition to secure design, solutions should follow secure programming practices, and that’s where the biggest challenge lies for software development companies. Both Oracle and SAP patch about 30 new software vulnerabilities each month (Oracle releases its updates quarterly), this is almost like having a new vulnerability every day. This is far from the desired level in secure solutions.
Software vulnerabilities, for example, in SAP Systems, comprise of 80%, while Design and Architecture issues make up less than 20%, according to the analysis of 3000 vulnerabilities in SAP. In typical applications, those figures are even lower than 20%.
Software vulnerabilities can be used to gain unauthorized access to organisation’s applications even if they have a perfect security architecture, encryption, and other security measures in place. It’s like an open window near the armored door.
To sum up, when applications move to the cloud, one single error can be used to get access to all clients very quickly. For instance, our Director of Treat Intelligence Matheu Geli has recently identified a very critical vulnerability in SAP HANA cloud, which can be exploited to get access to 6400+ organizations. The good news here is that this issue was patched by SAP very promptly, i.e. only within 2 weeks while usually it may take anywhere from 3-18 months.