Secure Application Development And Modern Defenses

Abstract

When it comes to the internet, security has always been an after-thought. A great evidence to support the theory can be seen when we look at the history of the internet. The internet was created by US military back in 1969, branded as "Arpanet" at that time. In 1973, ARPANET created TCP IP protocol suite which later enabled the development of protocols such as "SMTP, POP3, FTP, TELNET " in 1980's and HTTP in 1991. 

All of these protocols could be easily eaves-dropped upon by an attacker as they do not encrypt the traffic. Their secure versions were released only later, such as FTPS, SMTPS, SSH, and HTTPS since at that time connecting people and building features was the priority.  If security would have been present by design, we would not have encountered these problems today. 
The same is the case of when we develop the products today, we consider security to be an after-thought rather than an in-built feature, as a reason of which, security breaches occur.  In this article, we would talk about secure application development and why SDLC (System Development Lifecycle) is an ideal model for building secure products.

The model leads "Security By Design" and "In-depth Defense" approach. The idea behind this model is that security should be an essential part of all phases of SDLC so that the bugs are addressed during the early stages of development. Fixing security issues at earlier stages of the development cycle directly reduces costs, time, effortand resources.

Application Layer Security Attacks

As time passes by, we witness a rise in application security attacks, an upward progression in layer of insecurities of the OSI model. In 80 and 90's most of the attacks were related to Layer 1, Layer 2 and Layer 3 of the OSI model, ​today we are at the point that we have developed a great defense at Network Level, however application layer security remains a big challenge. 

According to a report by Gartner Research, it states that 75% of the attacks today occur at the application layer of the OSI Model. According to a survey by Trustwave, 82% of web applications are vulnerable to XSS attacks. According to another survey, 80% of all the security incidents in the financial sector occur due to Cross-site Scripting. Therefore, building defense at application layer is mandatory.

Application Layer Defenses/Approach

Overtime, there have been multiple defenses and approaches established at application level, most notable being a "Web Application Firewall" and "Runtime Application Self-Protection" so on and so forth.  

A Web Application firewall could be used as an additional layer of security, however all WAF's rely upon Blacklist i.e. Reject Known Bad, as whitelisting mode is not practically applicable in the real world (it's not easy to implement). This can be largely attributed to the fact that the majority of web applications are dynamic, and it is very difficult to predict all the possible inputs in order to write a whitlelist of what is allowed. The blacklist, however is not really effective, and this has been proven in past. As a matter of fact, Bypassing WAF's is my day-to-day job and back in 2013, I had written a cheatsheet "Bypassing Modern WAF's XSS Filters" for bypassing Web Application firewalls in which I had written bypasses for top Web Application firewalls. 

Runtime Application Self Protection is relatively a new approach for preventing application layer attacks, which empowers the application to protect in against attacks in real time. A RASP sits at each junction point of the application such as between the application and database, the file system and the network, it sits there and identifies & blocks any malicious activity, enabling the application an ability to protect itself. The problem, however, with this solution is that it still is based upon a blacklist, it is very costly and requires a lot of time to mature itself. 

“The cost of removing an application security vulnerability during the design phase ranges from 30-60 times less than if removed during production.”- NIST, IBM, and Gartner Group

Bottom line is that, You cannot write a vulnerable code and rely upon WAF, RASP and other protection mechanisms to protect your application. 

Secure SDLC 

The defenses we talked about above do help in improving our security model. However, in my opinion, it is the wrong way of solving the problem. The best approach is that the application should itself carry the ability to protect itself and henceforth, be built with security in mind from day one. Experts recommend that security should be embedded into all stages of SDLC i.e. Requirements gathering, Design, Development, Testing, Implementation.

Let's talk about how security could fit into all stages of SDLC:

i) Requirements

The first phase of SDLC is the "Requirement" in which project scope and goals are set.  In this phase, OWASP recommends the establishment of security requirements of the application. The requirements of the customer should be checked in accordance with the security standards such as the password policies, secure network protocols etc. 

ii) Design 

In the design phase, OWASP recommends the building of design with security in mind. This involves what is known as Threat modelling, which is an approach that involves analyzing the security of an application in order to mitigate the threats which yields the security plan. ​ The following is a great presentation on how threat modelling should be performed. 

iii) Development 

In Development phase, OWASP recommends developers to follow "Secure Coding Standards" for which, the organization must conduct an awareness on Secure Coding for developers, because guidelines are often overlooked by developers. Apart from that Source code, reviews must by done by internal team. It is also recommended to have this conducted via third party to mitigate additional findings.

iv) Testing 

In testing phase, OWASP recommends performing a penetration test including infrastructure assessment, in order to counter verify if the findings present inside the design and development phase have been properly fixed. Both Static and Dynamic code analysis should be thoroughly performed. 

Special attention should be paid to Business logic bugs which cannot be otherwise found by automated scanners as the business logic varies for every application. Efforts made in second phase i.e. Design could reduce the number of business logic bugs significantly. 

v) Deployment 

Deployment is a phase where your application goes from development into production environment. In this phase, OWASP recommends securely conducting the migration process from development phase to production phase and to ensure that post production security requirements are met.

In case you would like to learn more about Secure SDLC, I would recommend the following presentation - "Secure Development Lifecycle".

Security is an ongoing process, no specific requirement has to be met for 100% security. 

It should be noted that even after introducing security in every process of SDLC, 100% security cannot be achieved. However, the threat probability could be reduced. As security analysts, we have to close a 100 doors from which an attacker could enter and as an attacker, s/he only needs one door.  The fact that appeals most to me about this approach is that it's proactive, not reactive which is how most of the application development nowadays is done. ​