Hacking: The case for prevention rather than cure
Amit Ashbel explains how source code is the one advantage vendors have over hackers and how testing code earlier in the development process can prevent many of the vulnerabilities that hackers exploit today
Amit Ashbel, cyber-security evangelist, Checkmarx
When the movie Sneakers came out in 1992, hacking wasn't considered a real threat; it was almost something cool that really clever kids did just to prove they could. More than two decades later, hacking has taken on a far more sinister tone and become a much more profitable profession. With breaches continuing to happen at an alarming rate, the proliferation of cyber-crime is a huge threat to corporate organisations and individual consumers alike. In a bid to counter this current trend, and threat, we go back five centuries to the Dutch philosopher, Desiderius Erasmus to borrow his idea of 'prevention is better than cure'.
The pace of technology
One of the reasons why there are so many breaches is because of the increasing volume of connected devices - a result of technological advances. We live in a world where new devices, platforms, applications or systems are launched every day, each of which presents a new surface attack area and unfortunately without any regulation or industry standards, security has been less of a priority than getting these new products to market. Developers are still measured by how quickly they can write application code and therein lies the problem; security, unfortunately, is often an afterthought and developers are usually involved in the process far too late.
The root of the problem
So whilst there are numerous technology solutions that will help protect organisations against cyber-crime and many hacking tools and techniques that any serious cyber-security professional will be familiar with, the root of the problem remains, for the most part, un-tackled and that is the root application code. Currently this code, because it is not developed with security in mind, is released to the market with both bugs and vulnerabilities. But, if we could prevent this from happening in the first instance, we would not need to focus so much on curing the problem, either through re-coding or potentially, the deployment of wider security solutions.
The software development life cycle (SDLC)
The normal process for software development, or the software development life cycle (SDLC), has five main stages: design, development (coding), testing, deployment and maintenance. Currently, most of the testing is conducted at the latter end of the cycle, which introduces a variety of problems.
Black box testing
Testing late with black box methods such as pen-testing is an expensive and time-consuming business with the added downside that pen-testing can only ever be as good as the individual pen-tester. Testing so late in the process also means that it takes longer for the coders to re-code to fix any bugs or vulnerabilities found as they are not as familiar with the code as they would have been when they first wrote it which, in turn, costs the business more money. It also puts pressure on the business to release a new version that isn't fully patched due to time and budget constraints. Often, there will have to be a decision made between fixing a bug so that a feature will work perfectly for the user of the application or fixing a security vulnerability, because they simply don't have the time or budget left to do both. In a competitive marketplace, the features are often considered more important and so vendors decide to take the risk. This sometimes happens with the view to fixing the vulnerability in a later version of the application but of course, with development cycles getting increasingly shorter and the focus always on new features, this rarely happens.
White box testing
White box testing methods such as Static Application Security Testing (SAST) rely on possibly the only advantage a vendor has over the hackers – the source code. Access to the application's source code allows white box tools to build a comprehensive understanding of the risks, which might be exposed. Analysing a full code base can be a time- consuming process. In many cases, analysis has to be performed on millions of lines of code (LoC). Such a process could take many hours or even last a full day. In an agile and continuous development environment, release timelines don't permit these long cycles of analysis. Newer SAST solutions allow incremental scanning so developers can test the relevant/modified pieces of code, for security flaws rather than run a full, time consuming scan for every new build released.
The advantage of white box testing solutions goes beyond the detection stage though; a strong SAST solution enables developers to identify their coding mistakes and address them early in the process, thus reducing the costs of handling vulnerabilities at a later stage of the SDLC and eliminating the “cost of delay” caused by late detection of application security issues, which in many cases causes a project delay. Moreover, new generation SAST solutions also have the ability to reduce the developer's mitigation effort and reduce remediation time by pinpointing specific junctions in the data flow of the application's code, which allows mitigating multiple vulnerabilities with a single fix. This functionality on its own can reduce remediation times by up to 80 percent in many cases.
Beyond the educational advantage of learning how to code securely, developers start addressing vulnerabilities in the same way they address functional bugs, transforming an SDLC into a secure-SDLC (sSDLC). If security can be considered at the outset of the process, you can consider which security mechanisms need to be implemented where, how the attack surface can be minimised, and identify sensitive areas where secure development can be helped by providing a secure infrastructure for developers to work with. Once this mindset is developed and security is at the core of the SDLC, we have a much better chance of preventing vulnerabilities that hackers can capitalise on.
Contributed by Amit Ashbel, cyber-security evangelist, Checkmarx