Why Care About Application Security At All?

Why Care About Application Security At All?


There has been an enormous shift in the attack vectors of cyber attacks in the last few years. With the digital transformation initiatives taken by almost every company in every industry the applications lie at the heart of each business. This means more lines of code written in a rush to keep pace with the competition and security is more often than not overlooked in the process.

It would be simply too optimistic to assume that hackers are not aware of this frustrating situation. As expected, they have shifted their efforts towards vulnerabilities in software rather than trying to penetrate networks protected by well-established and reliable network security tools. Even if they manage to infiltrate the systems through network, widely adopted SIEM and SOAR tools leave them little time to play around whereas application layers are mostly left unattended. Latest report by IBM in July 2019 shows, the cost of a breach has now reached almost 4 million USD on average and roughly 1.000 new vulnerabilities are reported each month.

Below is a chart from Forrester, The State of Application Security 2019 report that shows software vulnerabilities and web applications were two most common attack vectors in a survey conducted among 257 network security professionals whose companies had an external security breach in the past one year.

Why Care About Application Security At All?

Conducting penetration tests a few times a year can make you feel comfortable but without having continuous secure development practices in place, you basically leave your applications vulnerable to attacks until the next penetration test time.

The involvement of development teams is also quite low when penetration tests are the single source of information relating to the security health of your projects. Actually, the only time they are asked to be involved is when somebody needs to dive into those grueling pdf reports and fix the issues.

Considering the recent developments in the architecture of applications such as APIs, microservices and containers it is getting even harder to secure each layer involved in the pre and post deployment stages of software development. The lack of security engineers coming from software development background requires training old network security professionals on secure coding practices which also is a painful process that brings about same old difficulties associated with resistance to change.

As a result, the graph below from Microfocus Application Security Risk Report 2019 depict the amount of risk both web and mobile applications have.

Why Care About Application Security At All?

Lately, we come across more and more companies that are transitioning to micro-services and the shift to micro-services comes with a wrong belief that having smaller pieces of software responsible from smaller tasks running on their own environment and communicating through API’s will lead to fewer vulnerabilities. Surprisingly, studies indicate that due to increase in attack surfaces, average number of vulnerabilities identified in 100.000 lines of code is almost 4-5 times higher than those in traditional architectures. So, if you are considering or in the midst of a transition to micro-services, maybe API Security should start to be one of your concerns.

Container security is also coming into the picture with the proliferation of containerized structures across enterprises. All these brand new concepts require a brand new and holistic approach for handling the upcoming problems stemming from multiple structures embedded in the application security.

The numbers from the Whitehat’s Application Security Statistics Report 2019 in the image below clearly speak for themselves. The mean time to fix vulnerabilities is too long and the remediation rates are too low.

Why Care About Application Security At All?

There is one key take-away from the numbers though. Vulnerabilities identified by SAST tools which scan the source code or binaries in the development phase are fixed much more quickly (around 3 times) than those discovered by DAST(dynamic application security testing tools that attack your application with an outside in approach, mimicking the behaviors of hackers) tools which run in the testing phase at the earliest as they require a production like environment to run. As we always say, the earlier a vulnerability is identified in your software development life cycle, the easier and less costly it is to fix

Despite all the efforts to remediate as many vulnerabilities as possible, 55% is the best remediation rate across all severity levels both in SAST and DAST findings. This means that even in the best scenario, 45% of critical vulnerabilities are left to their fates even if your applications are scanned by SAST and DAST tools. This is not a catastrophic situation though, as long as you ensure that vulnerabilities that are not remediated are those that are not relevant considering the infrastructure and architecture of your applications. However, this requires going through an elaborate threat modelling process which is a critical and one of the most challenging parts of application security.

The numbers above are presented by no means to scare you off, but to show you how much there is to do regarding application security. If you rely on web application firewalls or other network security tools to protect your applications, maybe it is time to think about securing the application layer during the entire software development life cycle. A multi-layered security approach is a must in order to achieve better security posture. It is never too late and it is certainly possible to turn the disadvantage of stepping in a little later into an advantage of building a solid foundation that consists of the right tools and processes from the start. Some practices associated with application security such as threat modelling can also be helpful with other matters such as GDPR which is on the verge of becoming a real threat to businesses in case of a breach of the regulation. In our next post, we will look at how we can build and improve our AppSec posture.