Secure Application Development And Modern Defenses

<div dir="ltr" style="text-align: left;" trbidi="on"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixQhMOndWwvmUt_x8xHUnTSX7uk8n-d9kWDEWBMAGZSzbhtVIHtsPbqko6pTBF5qGsBUktN4odSm9YX98vicvKd9IlTARdmm0pbkn1IkMlLyehXDKF5__4BOOlEQhZWLMzuTGYJBVbd3w/s1600/hacker+security-med_.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="258" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixQhMOndWwvmUt_x8xHUnTSX7uk8n-d9kWDEWBMAGZSzbhtVIHtsPbqko6pTBF5qGsBUktN4odSm9YX98vicvKd9IlTARdmm0pbkn1IkMlLyehXDKF5__4BOOlEQhZWLMzuTGYJBVbd3w/s400/hacker+security-med_.jpg" width="400" /></a></div><div rtenodeid="3" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><h4>Abstract</h4></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">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. </span><br /><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><br /></span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">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. </span><br /><a name='more'></a>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.<br /><br />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.</div><div rtenodeid="4" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><h4>Application Layer Security Attacks</h4></div><div rtenodeid="4" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">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. </span><br /><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><br /></span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">According to a report by Gartner Research, it states that 75% of the attacks today occur at the application layer of the OSI Model.</span> 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.</div><div rtenodeid="4" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><h4>Application Layer Defenses/Approach</h4></div><div rtenodeid="4" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">Overtime, there have been multiple defenses and approaches established at application level, most notable being a "<b>Web Application Firewall</b>" and "<b>Runtime Application Self-Protection</b>" so on and so forth.  </span><br /><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><br /></span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">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 "<b><a href="http://www.rafayhackingarticles.net/2013/12/bypassing-modern-wafs-xss-filters-cheat.html" target="_blank">Bypassing Modern WAF's XSS Filters</a></b>" for bypassing Web Application firewalls in which I had written bypasses for top Web Application firewalls. </span><br /><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><b><br /></b></span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><b>Runtime Application Self Protection </b>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. </span><br /><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><br /></span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">“<b>The cost of removing an application security vulnerability during the design phase ranges from 30-60 times less than if removed during production.</b>”- NIST, IBM, and Gartner Group</span><br /><div style="font-family: calibri, arial, helvetica, sans-serif; font-size: 16px;"><br /></div><div style="font-family: calibri, arial, helvetica, sans-serif; font-size: 16px;">Bottom line is that,<strong> You cannot write a vulnerable code and rely upon WAF, </strong><span rtenodeid="28" style="font-size: 12pt;"><strong>RASP and other protection mechanisms to protect your application. </strong></span></div></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><h4>Secure SDLC </h4></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><div style="font-family: calibri, arial, helvetica, sans-serif;"></div><div style="font-family: calibri, arial, helvetica, sans-serif; line-height: 150%;"><span style="font-family: "calibri" , sans-serif;">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.<o:p></o:p></span></div></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmvs6B5waVwKIzk71B5bYydVoG2I71gRkJNcrbrD9MaPDqCdEdn2DLMt2Btw9efL8BHRhIh612qrNQbpm1px_NLog2ZfmZf0i3iFNf2LiHN2bWYoB4K7zRl8aWqqvpuGJJLM-08tM4kuc/s1600/600px-Security_in_the_SDLC_Process.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="370" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmvs6B5waVwKIzk71B5bYydVoG2I71gRkJNcrbrD9MaPDqCdEdn2DLMt2Btw9efL8BHRhIh612qrNQbpm1px_NLog2ZfmZf0i3iFNf2LiHN2bWYoB4K7zRl8aWqqvpuGJJLM-08tM4kuc/s640/600px-Security_in_the_SDLC_Process.png" width="640" /></a></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;">Let's talk about how security could fit into all stages of SDLC:</div><div rtenodeid="38" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><br rtenodeid="39" /></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><strong>i) Requirements</strong></div><div rtenodeid="41" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><div style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;"><br /></span></div><div style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;">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. <o:p></o:p></span></div></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><br /></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><strong>ii) Design </strong></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><div style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;">In the design phase, OWASP recommends the building of design with security in mind. This involves what is known as <span style="background: white;">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. </span><o:p></o:p></span></div><div style="line-height: 150%;"><br /></div></div><iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/ZtSrcq7gscE" width="577"></iframe> <br /><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><strong><br /></strong></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><strong>iii) Development </strong></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><div style="line-height: 150%;"><br /></div><span style="font-family: "calibri" , sans-serif; line-height: 150%;">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.</span><br /><strong><br /></strong><strong>iv) Testing </strong></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><div style="line-height: 150%;"><br /></div><div style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;">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. <o:p></o:p></span></div><div style="line-height: 150%;"><br /></div><div style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;">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. <o:p></o:p></span></div><br /><div style="line-height: 150%;"><br /></div><strong>v) Deployment </strong></div><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;"><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><br /></span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">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.</span><br /><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;"><br /></span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif;">In case you would like to learn more about Secure SDLC, I would recommend the following presentation -</span><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif; font-size: 16px;"> "</span><strong style="font-family: calibri, arial, helvetica, sans-serif; font-size: 16px;"><a href="https://www.owasp.org/images/7/76/Jim_Manico_(Hamburg)_-_Securiing_the_SDLC.pdf" target="_blank">Secure Development Lifecycle</a></strong><span style="font-family: "calibri" , "arial" , "helvetica" , sans-serif; font-size: 16px;">".</span></div><div rtenodeid="74" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; text-decoration: underline;"><strong style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;"><br /></span></strong><strong style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;">Security is an ongoing process, no specific requirement has to be met for 100% security. </span></strong></div><div rtenodeid="76" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; text-decoration: underline;"><br /><div style="line-height: 150%;"><span style="font-family: "calibri" , sans-serif;">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. ​<u style="text-decoration: underline;"><o:p></o:p></u></span></div></div></div>

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 w...

+ Read more »