Amit Ashbel, Cyber Security Evangelist, Checkmarx, explains why automated application security testing is the first step in combating cyber crime.
The world is moving at an incredible pace. New technologies are regularly announced and whole ecosystems developed around them; such as the internet of things (IoT) for example. However, with these new developments come security risks to both businesses and consumers; hacking and cyber crime are now widely reported. The first step to combating these increased risks is to secure the application code in order to stop vulnerabilities at the root.
Automated application security testing is a vital part of this but how does automated testing work in practice and what are the benefits of an automated testing process for developers and businesses?
The connected risk
To understand the risks we are living with today, we just have to look at the IoT, a hugely beneficial technology but every IoT device created – cars, smartTVs, baby monitors – presents another attack surface for hackers. And with Gartner claiming that we will see over 25 billion connected things by 2020, that’s a lot of attack surfaces. Unfortunately, there are little to no regulations around creating these devices so security protocols are often absent which means that when consumers are prompted to type in email IDs, phone numbers, full names etc., they are doing so at great peril if there is a flaw in the application layer code. But uncovering and fixing vulnerabilities in the application code is a complicated issue if not done as part of a structured methodology using the correct tools and building the correct in‑house skill sets.
Manual development testing
The normal process for software development, or the software development lifecycle (SDLC), has five main stages: design, development (coding), testing, deployment and maintenance. Within this lifecycle, many organisations still employ the manual testing methods that have been in use for decades. This manual process involves three core stages. The first stage is synching, whereby the security teams interview the development teams to ensure they are familiar with the application. The second is reviewing, whereby the whole team reviews the entire application code in order to use everyone’s field of expertise. The third is reporting when each tester reports their findings. Once the false positives are eliminated, the findings are given to the developers. This is a lengthy process and developers, who are measured on time, have often moved on to other projects and are now far less familiar with the application and its code; the vulnerabilities have simply been detected too late. This is the root of the complicated decision between fixing bugs or vulnerabilities.
The second is reviewing, whereby the whole team reviews the entire application code in order to use everyone’s field of expertise. The third is reporting when each tester reports their findings. Once the false positives are eliminated, the findings are given to the developers. This is a lengthy process and developers, who are measured on time, have often moved on to other projects and are now far less familiar with the application and its code; the vulnerabilities have simply been detected too late. This is the root of the complicated decision between fixing bugs or vulnerabilities.
Bugs versus vulnerabilities
IoT products and updates are being released at an ever‑increasing pace and when security is only thought about late in the development process, such as with manual testing methods, there is usually only time to fix the bugs that could negatively impact the user’s experience or the vulnerabilities that could impact the security of the application, not both. Unfortunately, in the competitive technology marketplace, the vendor often chooses to fix the bug and come back to the vulnerability later rather than delay release. It is this unsecured root application code that presents the risk and why security needs to be built into the development process.
Automated testing process
Rather than wait until the development process is finished to test for flaws, automated application security testing is integrated into the development process and provides constant feedback, transforming an SDLC into a secure‑SDLC (sSDLC). Each change to the code is automatically analysed so developers are notified immediately about any vulnerabilities so vendors have a much better chance of preventing vulnerabilities that hackers can capitalise on. Of course, this also has the added benefit of encouraging better coding practices among the developers and building up their secure coding skills.
Static application security testing (SAST) solutions, or white box testing, can be integrated into all types of developer environments including waterfall, continuous integration and agile/DevOps, which are gaining in popularity for more complex projects. Static code analysis (SCA), a leading SAST solution, can be easily integrated into build automation tools and continuous integration servers and normally have wide programming language support which helps organisations that use a variety of programming and scripting languages on multiple frameworks.
Added benefits
From an organisational perspective, automated security application testing is better in terms of ROI than manual testing. It takes much more resource to test manually, specifically around scanning and analysing the code. With pen‑testing for example, a black box manual testing method, the testing is both expensive and time‑consuming with the added downside that it will only ever be as good as the individual pen‑tester. With automated security application testing, it takes less time and fewer people to scan the code and you don’t need to re‑scan unchanged code which saves more time, while avoiding the human error factor of manual testing. Automated application security testing is also better in locating the leading application‑layer vulnerabilities and is more capable of detecting code errors, dead code and other flaws that lead to buggy software.
The future for application security
Application security (AppSec) is a relatively new sector; according to the recent SANS State of Application Security report, only 26% of respondents consider their AppSec programmes to be ‘mature’ or ‘very mature’. But with 30% of respondents claiming to assign responsibility for security testing to the development team, up from 22% last year, things appear to be progressing in the right direction. The more organisations are building security into the SDLC, the more application code will be developed secure from vulnerabilities and therefore safer for both organisations and consumers.
The report also highlighted that the overwhelming majority of organisations (61%) expected to see spending on AppSec increase in future which is more good news for the sector. With an ever‑increasing number of new and updated applications being constantly released, organisations can’t underestimate the potential risk of every single one and the only way to stop this risk at source is to employ automated application security testing to stop vulnerabilities at the root – the application code. This is the first step in fighting, and beating, cyber crime.
This article was first published in the July 2016 issue of TEST Magazine. Edited for web by Cecilia Rehn.
